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ABSTRACT 


Information  technology  (IT)  projects  have  a  well-documented  potential  for 
complexity,  difficulty,  and  failure.  Typical  explanations  focus  on  project-related 
issues,  but  in  some  cases  success  or  failure  depends  less  on  the  project  and 
more  on  the  dynamic  interaction  of  organizational  factors  at  the  portfolio  level. 

This  thesis  focuses  on  the  interplay  of  explicit  and  implicit  organizational 
factors  in  complex  organizations,  and  their  effect  on  the  outcome  of  IT  projects. 
Through  implicit  organizational  factors,  a  poorly  executed,  unhealthy  project  may 
infect  healthy  projects,  similar  to  the  spread  of  a  contagion.  This  thesis  utilizes  a 
study  of  the  United  States  Coast  Guard  WatchKeeper  and  Mission  and  Asset 
Scheduling  Interface  systems’  development  as  an  example  of  the  contagion 
effect. 

Analysis  revealed  three  classes  of  implicit  organizational  factors  that 
impacted  project  outcomes:  capacity,  control,  and  funding  priorities.  From  an 
organizational  perspective,  implicit  factors  were  found  to  play  a  much  more 
significant  role  in  affecting  the  outcome  of  projects  than  explicit  factors.  This  is 
important  because  managers  at  various  levels  of  hierarchy  tend  to  focus  only  on 
explicit  factors,  often  ignoring  implicit  factors.  Several  recommendations  for 
improving  project  and  portfolio  management  are  presented  based  on  this  finding. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Investment  in  information  technology  (IT)  programs  has  been  identified  as 
a  critical  area  in  the  federal  government.  The  federal  IT  Dashboard  (2014)  shows 
total  fiscal  year  2013  IT  spending  at  nearly  $76B  for  28  agencies.  In  the 
Department  of  Homeland  Security  (DHS)  alone,  $5.6B  was  invested  in  345 
projects,  with  $4.5B  for  91  major  projects.  From  huge  enterprise  resource 
planning  (ERP)  systems  potentially  catering  to  hundreds  of  thousands  of  users, 
to  small  research  systems  with  hundreds  of  users,  successful  IT  development  is 
critical  to  the  functioning  of  organizations.  In  general,  much  of  the  IT 
development  expense  in  the  federal  government  involves  transitioning  from 
legacy  silo  systems  to  enterprise  spanning  systems  which  facilitate  sharing  of 
data  and  integration  of  IT  with  business  processes  at  all  levels  (Ross,  Weill,  & 
Robertson,  2006).  The  success  rate  of  such  endeavors  is  low. 

IT  development  is  typically  complex  and  difficult.  In  1994  the  Standish 
Group  published  the  original  chaos  report  which  detailed  only  a  16  percent  IT 
project  success  rate.  While  this  rate  has  increased  over  the  years,  the  potential 
for  “other  than  successful  results”  remains  uncomfortably  high  at  61  percent 
(Standish  Group,  2013,  p.  1).  A  recent  example  of  IT  project  difficulty  is  the 
healthcare.gov  website,  which  was  intended  to  allow  people  to  shop  online  for 
private  health  insurance.  Although  cost  estimates  vary  wildly  depending  on  the 
source,  the  contractor  was  awarded  $93M  (CGI  Federal,  2011)  to  construct  the 
site,  which  was  essentially  non-functional  upon  delivery.  Due  to  the  high  profile 
nature  of  the  failure,  additional  resources  were  immediately  committed  to  rework 
the  site.  At  this  time  an  overall  cost  estimate  is  not  available,  but  development 
obviously  exceeded  cost  and  schedule  projections  while  delivering  minimal 
functionality. 
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IT  development  and  project  management  have  been  the  subject  of  intense 
study  for  forty  years,  but  consistent  successful  implementation  remains  elusive. 
This  thesis  focuses  on  the  interplay  of  explicit  and  implicit  organizational  factors 
in  complex  organizations,  and  their  effect  on  the  outcome  of  IT  projects.  Through 
implicit  organizational  factors,  a  poorly  executed,  unhealthy  project  may  infect 
healthy  projects,  similar  to  the  spread  of  a  contagion.  This  thesis  utilizes  a  study 
of  the  United  States  Coast  Guard  WatchKeeper  and  Mission  and  Asset 
Scheduling  Interface  systems’  development  as  an  example  of  the  contagion 
effect.  Extensive,  in-depth  data  was  available  due  to  personal  involvement  in  the 
projects  by  the  author. 

Analysis  revealed  three  classes  of  implicit  organizational  factors  that 
impacted  project  outcomes:  capacity,  control,  and  funding  priorities.  From  an 
organizational  perspective,  implicit  factors  were  found  to  play  a  much  more 
significant  role  in  affecting  the  outcome  of  projects  than  explicit  factors.  This  is 
important  because  managers  at  various  levels  of  hierarchy  tend  to  focus  only  on 
explicit  factors,  often  ignoring  implicit  factors.  Several  recommendations  for 
improving  project  and  portfolio  management  are  presented  based  on  this  finding. 

B.  PROBLEM  AND  PURPOSE 

This  thesis  investigates  how  implicit  and  explicit  organizational  factors 
affect  the  success  of  IT  projects  within  an  enterprise  portfolio  and  how  contagion 
may  be  transmitted  between  projects.  The  U.S.  government  spends  billions  of 
dollars  per  year  on  IT  programs  which  exceed  schedule  and  budget  constraints 
while  delivering  less  than  promised  functionality  and  performance.  Research 
exploring  inter-portfolio  effects  may  lead  to  better  preparation,  planning,  and 
execution  of  IT  projects,  as  well  as  reducing  duplicative  systems.  Successful 
integration  of  enterprise  IT  systems  and  alignment  with  business  processes  is 
critical  to  overall  mission  success. 
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C.  RESEARCH  QUESTIONS 

•  How  can  development  of  interdependent  enterprise  IT  systems  be 
affected  by  shifting  portfolio  funding  priorities  and  clan  control? 

•  How  are  capacity  issues  recognized,  and  can  they  affect 
development  of  systems  within  an  IT  portfolio? 

•  Can  the  interaction  between  explicit  and  implicit  organizational 
control  factors  affect  enterprise  IT  system  development  within  a 
portfolio? 

D.  BENEFITS  AND  LIMITATIONS  OF  RESEARCH 

Enterprise  system  development  is  a  complex  and  difficult  area  in  which  to 
succeed.  Interoperable  and  networked  systems  continue  to  become  more  critical 
due  to  the  amount  of  digitized  data  available  for  use.  Development  of  new 
systems  typically  takes  place  in  an  IT  environment  comprised  of  various  legacy 
systems,  with  varying  degrees  of  peer  connectivity.  Creation  of  new  systems 
invariably  affects  existing  systems,  or  other  systems  in  concurrent  development. 
Investigation  of  organizational  factors,  their  interdependencies,  and  contagion 
theory  will  provide  useful  insight  to  managers  of  IT  development  projects  within 
enterprise  portfolios  as  well  as  portfolio  managers  themselves.  The  study 
contributes  evidence  meaningful  in  capacity  and  control  theory,  as  well  as  certain 
recommendations  specific  to  the  USCG.  The  thesis  does  not  attempt  to  provide  a 
simple,  overt  model  which  solves  this  incredibly  complex  problem.  Indeed,  the 
author’s  point  is  that  diligence  and  awareness  at  the  portfolio  level  are  critical  in 
an  attempt  to  minimize  (or  intelligently  focus  the  effect  of)  implicit  organizational 
factors.  Direct  applicability  to  all  enterprise  system  development  is  not  implied. 

E.  IT  PROJECT  SUCCESS 

Overcoming  the  difficulties  inherent  in  successful  development  of  complex 
IT  systems  has  become  an  industry.  Much  has  been  written  about  development 
methodologies,  cost  estimation,  and  project  management.  Given  the  high  stakes 
which  accompany  financial  commitments  of  this  magnitude,  varying  definitions  of 
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“success”  have  been  created  by  the  program  manager  trying  to  emphasize  the 
positives  in  a  challenged  or  essentially  failed  project. 

A  commonly  cited  example  in  the  Department  of  Defense  (DOD) 
community  is  the  United  States  Air  Force’s  (USAF)  Expeditionary  Combat 
Support  System  (ECSS).  Upon  cancellation  in  late  2012,  the  system  had  been  in 
development  for  seven  years  at  a  cost  of  over  $1B,  with  negligible  capability.  In 
addition,  the  USAF  estimated  another  $1 .1 B  would  be  required  in  order  to 
achieve  one  quarter  of  the  functionality  originally  promised,  with  system  delivery 
in  2020  (Government  Accountability  Office  [GAO],  2013b;  Reilly,  2012;  USAF, 
2012b).  Following  cancellation,  Congress  and  industry  experts  alike  wondered 
how  a  failure  of  this  magnitude  had  been  allowed  to  happen,  and  why  it  had  not 
been  cancelled  earlier.  When  Robert  Shofner,  the  Air  Force’s  program  executive 
officer  for  business  and  enterprise  systems  was  asked  this  question,  he  called 
that  “speculative”  (Reilly,  2012,  p.  3).  The  GAO  investigated  several  “Major 
Automated  Information  Systems  [MAIS]”  in  a  2013  report.  Although  many 
contributing  causes  were  outlined  for  incomplete  or  failed  systems,  the  focus 
during  challenged,  multi-year  developments  hinged  on  redefining  “success”  and 
lowering  expectations.  In  the  “impact”  section  of  the  USAF  statement  on  ECSS 
cancelation,  they  focus  on  the  “success”  of  other  systems,  rather  than  the  ECSS 
failure: 


ECSS  was  one  part  of  our  overall  logistics  transformation  effort. 
Expeditionary  Logistics  for  the  21st  Century  (eLog21)  was  the 
overarching  transformation  campaign  to  fundamentally  change  the 
way  logistics  is  accomplished  Air  Force  wide.  Since  the  eLog21 
campaign  started  in  2003,  numerous  logistics  and  supply  chain 
initiatives  have  been  successfully  implemented  to  improve  AF 
processes,  policies,  and  technology.  To  name  a  few  examples,  we 
leveraged  Item  Unique  Identification  marking  process  to  cleanse 
1.4M  records  within  the  Air  Force  Equipment  Management  System 
to  better  support  Asset  Marking  and  Tracking.  In  addition,  we 
developed  standardized  processes  and  tools  for  implementing 
proactive  engineering  concepts  to  improve  Weapon  System 
Sustainment.  Finally,  we  developed  and  implemented  the  Aircraft 
Availability  Improvement  Program.  The  [US]AF  has  ongoing 
initiatives  to  continue  to  transform  AF  wide  logistics  planning, 
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resources  and  repair  planning,  data  accuracy,  centralized 
assessment  management,  and  predictive  maintenance.  Despite  the 
cancellation  of  ECSS,  the  AF  remains  committed  and  will  continue 
to  transform  our  logistics  business  processes.  (USAF,  2012a,  p.  1) 

The  statement  above  nearly  portrayed  ECSS  as  an  incidental  and 
noncritical  portion  of  a  larger  effort,  despite  representing  a  $1 B  waste  of  funds. 

Even  the  Navy  ERP  system,  which  is  often  hailed  as  a  “success,”  was 
delivered  late,  over  budget,  and  with  a  functional  subset  much  less  than  originally 
conceived.  According  to  Perera: 

When  measured  against  its  original  baseline,  the  lifecycle  cost  of 
Navy  ERP  has  grown  by  about  31  percent  as  of  September  2012, 
to  $2.6  billion.  It  is  also  2  years  behind-auditors  attribute  slippages 
to  system  performance  problems  and  the  emergence  of 
unanticipated  requirements.  The  GAO  also  notes  that  as  of 
December  2012,  Navy  officials  reported  that  560  system  defects 
remained  unresolved.  (2013,  p.  1) 

While  the  above  facts  could  be  interpreted  as  “other  than  successful,”  the  Navy 
and  those  in  charge  of  program  development  frame  the  program  as  a  “qualified 
success”:  “Since  2006,  ERP  costs  have  stabilized  and  the  program  has  been 
successfully  implemented  at  three  SYSCOMs  [system  commands]”  (RAND, 
2012,  p.  16).  The  Navy  notes  the  ERP  program  promotes  fiscal  responsibility 
“while  significantly  reducing  the  cost  of  doing  business”  through  standardization 
of  business  processes  and  common  data  sets  (U.S.  Navy  [USN],  2014,  p.  1). 

With  such  a  wide  and  variable  definition  of  “success”  in  IT  project 
development,  a  common  framework  is  helpful  in  attempting  to  categorize  project 
results  while  removing  the  human  desire  to  avoid  acknowledging  negative 
results.  This  thesis  follows  the  widely  utilized  categories  put  forth  by  the  Standish 
Group: 

•  Resolution  Type  1 ,  or  project  success:  The  project  is  completed  on- 
time  and  on-budget,  with  all  features  and  functions  as  initially 
specified.  (1995,  p.  2) 
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•  Resolution  Type  2,  or  project  challenged:  The  project  is  completed 
and  operational  but  over-budget,  over  the  time  estimate,  and  offers 
fewer  features  and  functions  than  originally  specified.  (1995,  p.  2) 

•  Resolution  Type  3,  or  project  impaired:  The  project  is  cancelled  at 
some  point  during  the  development  cycle.  (1995,  p.  2) 

Although  challenges  to  the  Standish  categories  exist,  and  alternate 
definitions  have  been  presented,  the  Standish  definition  is  sufficient  for  the 
purposes  of  this  thesis.  Under  this  classification  system,  WK  would  be  rated  as 
resolution  type  two,  while  MASI  could  be  argued  as  either  type  two  or  type  three. 

F.  METHODOLOGY  PART  I— OVERVIEW 

This  qualitative  study  utilizes  a  grounded  theory  and  case  study  approach. 
According  to  Cresswell,  grounded  theory  is  a  process  which  “involves  using 
multiple  stages  of  data  collection  and  the  refinement  and  interrelationship  of 
categories  of  information”  (2009,  p.  13).  The  case  study  involves  the  in-depth 
exploration  of  “a  program,  event,  activity,  process”  and  is  “bounded  by  time  and 
activity”  (Cresswell,  2009,  p.  13).  Extensive  detailed  information  was  collected  by 
a  participant  observer  during  the  case  time-frame  to  include  hundreds  of  files, 
emails,  and  design  documents.  The  participant’s  placement  within  the  case  study 
program  afforded  unique  personal  insight  and  access  to  materials.  An  open 
coding  scheme  was  utilized  to  generate  information  categories,  and  selective 
coding  was  used  to  explain  the  “story  from  the  interconnection  of  these 
categories”  (Cresswell,  2009,  p.  184).  Rather  than  beginning  with  a  theory, 
hypotheses  were  allowed  to  emerge  from  the  study  (Oorschot,  Akkermans, 
Sengupta,  &  Wassenhove,  2013). 

Validity  is  supported  through  the  use  of  multiple  strategies  (Cresswell, 
2009).  Triangulation  involves  utilizing  “different  data  sources  of  information  by 
examining  evidence  from  the  sources  and  using  it  to  build  coherent  justification 
for  themes”  (Cresswell,  2009,  p.  191).  In  this  study,  event  analysis,  analysis  of 
archival  data,  and  extensive  data  collected  by  the  participant  observer  were 
utilized  to  enable  triangulation.  In  addition  to  triangulation,  a  narrative  description 
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was  utilized  to  clarify  complex  sequences  of  events.  The  participant  bias  was 
clarified  and  the  author  was  in  the  field  with  involved  individuals  during  the 
majority  of  the  program  duration.  As  a  final  measure,  member  checking  was 
utilized  in  critical  areas.  From  the  study  and  the  analysis,  and  in  line  with  the 
grounded  theory  approach,  several  themes  emerged  which  are  discussed  in 
detail. 

The  organizational  structure  of  the  thesis  separates  and  simplifies  the 
study  and  results.  Chapter  II  explores  relevant  related  academic  theory  and 
studies,  forming  a  strong  platform  upon  which  to  base  the  analysis.  Chapter  III 
presents  CG  specific  background  information  which  enables  understanding  of 
later  narratives.  The  complex  CG  hierarchical  and  directorate  structure  is 
explained,  as  well  as  CG  acquisition  and  IT  development  procedures.  The  final 
section  of  Chapter  III  details  the  analysis  methodology  and  validity  support. 
Chapter  IV  contains  the  case  study  analysis  using  the  framework  of  Chapter  II  as 
a  lens,  and  references  the  important  detailed  events  described  in  Appendix  A. 
Chapter  V  summarizes  the  results,  provides  insight  into  possible  solutions,  and 
details  further  research  opportunities. 
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II.  CONCEPTUAL  FRAMEWORK  (LITERATURE  REVIEW) 


A.  ENTERPRISE  IT  SYSTEMS  PORTFOLIO 

1.  Rationale  for  Enterprise  IT 

Successful  complex  organizations  rely  heavily  on  enterprise  systems  to 
make  them  “better,  faster,  and  more  profitable  at  what  they  [do]”  (Ross  et  al., 
2006,  p.  vii).  Chen,  Sun,  Helms,  and  Jih  note  that  managing  an  IT  portfolio  “can 
be  conceptualized  as  an  issue  of  aligning  organizations  with  their  IT  to  gain 
competitive  advantages”  (2008,  p.  366;  Reich  &  Benbasat,  2000).  Gronau  and 
Rohloff  point  out  the  “necessity  of  adjustment  for  information  systems  according 
to  organizational  environment”  (2008,  p.  1077)  is  critical  because  both  business 
strategies  and  technology  continually  evolve  (Luftman,  2003).  When 
organizational  goals  or  priorities  change,  the  enterprise  architecture  vision  and  IT 
systems  must  align  to  the  new  processes,  or  disconnects  occur  between  the 
operation  of  the  organization  and  the  critical  support  provided  by  the  enterprise 
systems.  If  the  IT  systems  are  too  difficult  to  change,  organization  processes 
may  require  modification  to  align  to  the  systems.  Ross  et  al.,  define  enterprise 
architecture  as  “the  organizing  logic  for  business  processes  and  IT  infrastructure 
reflecting  the  integration  and  standardization  requirements  of  the  company’s 
operating  model”  (2006,  p.  47).  An  organization’s  operating  model  determines 
the  key  focus  of  IT  initiatives,  but  the  “key  to  effective  enterprise  architecture  is  to 
identify  the  processes,  data,  technologies,  and  customer  interfaces”  (Ross  et  al., 
2006,  p.  47). 

Enterprise  architecture  is  a  broad  area,  and  several  books  have  been 
written  on  the  topic.  The  discussion  here  does  not  address  enterprise 
architecture  and  how  to  implement  it,  but  rather  a  common  side  effect  of  an  initial 
lack  of  enterprise  thinking  when  developing  IT  solutions.  The  lack  of  enterprise 
thinking  and  resulting  IT  systems  eventually  limit  business  agility  and  growth. 
Many  businesses  and  agencies  fell  into  this  trap  organically,  including  the  USCG, 
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which  will  be  used  as  an  example.  The  trap  is  the  creation  of  IT  silos,  or  isolated 
IT  solutions  within  an  organization.  An  IT  silo  refers  to  a  system  designed  to  meet 
a  specific  local  business  need.  The  problem  occurs  when  the  business  later 
realizes  their  execution  is  limited  by  the  lack  of  system  interoperability.  Ross  et 
al.  describe  the  situation:  “Individually,  the  applications  work  fine.  Together,  they 
hinder  companies’  efforts  to  coordinate... and  the  company’s  data,  one  of  its  most 
important  assets,  is  patchy,  error-prone,  and  not  up  to  date”  (2006,  p.  6-7). 

The  USCG  traces  its  roots  to  the  Revenue  Cutter  Service,  formed  in  1790. 
In  1915,  the  United  States  Life-Saving  Service  merged  with  the  Revenue  Cutter 
Service  to  create  the  Coast  Guard.  In  1939,  the  United  States  Lighthouse 
Service  also  merged  with  the  USCG  as  well  as  the  Bureau  of  Marine  Inspection 
and  Navigation  in  1942.  At  various  points  during  its  history,  the  CG  has  been 
placed  under  the  Department  of  the  Treasury  (1790),  the  Department  of 
Transportation  (DOT)  (1967),  and  in  2003  was  placed  under  the  Department  of 
Homeland  Security  (DHS)  (USCG  Historian’s  Office,  n.d.).  Even  with  paper 
records  and  methods  prior  to  the  computer  era,  the  CG  was  a  mix  of  merged 
entities  under  several  different  agencies.  Business  processes  were  created  and 
optimized  at  local  levels,  or  within  individual  business  units.  During  its  tenure 
under  the  DOT,  information  systems  became  prevalent  as  well  as  networks  and 
the  World  Wide  Web.  Certainly  the  switch  to  management  under  DHS  took  place 
when  the  CG  had  numerous  IT  systems  in  place.  Is  it  any  wonder  IT  systems 
were  created  which  are  unable  to  communicate  with  each  other  or  share  data? 

In  complicated  environments  with  many  siloed  systems,  direct  database  to 
database  and  direct  system  connections  are  often  created  one  at  a  time,  for  valid 
reasons,  until  they  are  unmanageable  as  a  group.  This  undesirable  method  leads 
to  a  web  of  interconnections  where  a  change  to  a  single  system  can  force 
changes  to  all  connected  systems,  or  result  in  system  failure  when  an 
interconnection  goes  unnoticed.  Eventually,  management  of  the  tangled  systems 
is  no  longer  practical.  Many  businesses  have  found  themselves  considering 


10 


overarching  enterprise  architecture  after  realizing  their  legacy  systems  are 
inadequate  and  unsustainable  in  view  of  current  business  demands. 

2.  Interconnection  of  Enterprise  Systems 

Enterprise  IT  systems  often  share,  access,  or  modify  the  same  data. 
Certain  enterprise  systems  may  be  considered  the  “system  of  record,”  or  the 
“authority”  for  specific  data,  which  is  then  shared  with  other  systems.  According 
to  Marechaux,  “Today's  business  applications  rarely  live  in  isolation.  They  need 
to  be  connected  in  order  to  create  an  integrated  solution  from  which  an 
organization  can  derive  value”  (2006,  p.  1). 

A  popular  method  for  facilitating  data  sharing  and  interaction  of  enterprise 
systems  is  use  of  an  enterprise  service  bus  (ESB)  which  combines  the  virtues  of 
service-oriented  architecture  (SOA)  and  event-driven  architecture  (EDA).  SOA 
has  become  widely  advocated  as  an  enabler  of  business  agility  and  as  a  tool  to 
increase  alignment  of  business  goals  and  IT  (Bieberstein,  Bose,  Fiammante, 
Jones  &  Shah,  2006;  Chen,  Kazman,  &  Perry,  2010;  Choi,  Nazareth,  &  Hemant, 
2013).  As  previously  mentioned,  many  organizations  have  legacy  information 
system  silos.  Enterprise  IT  architecture  favors  process  driven  enterprise  tools 
over  function  driven  silos.  SOA  supports  this  method,  as  shown  in  Figure  1 . 
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Figure  1. 


EDA  complements  SOA.  While  SOA  operates  using  a  request/reply 
mechanism,  EDA  utilizes  an  asynchronous  publish/subscribe  method.  By 
combining  the  two  concepts  the  ESB  allows  for  a  wide  range  of  communications 
between  systems.  SOA  enables  one-to-one  connections,  while  EDA  allows  one- 
to-many  or  many-to-many  publications.  Applications  within  the  portfolio  publish 
services  which  other  applications  consume.  Some  systems  accept  write-backs 
from  other  systems  or  users.  According  to  Marechaux, 

SOA  is  an  architectural  concept  in  which  all  functions,  or  services, 
are  defined  using  a  description  language  and  where  their  interfaces 
are  discoverable  over  a  network.  The  interface  is  defined  in  a 
neutral  manner  that  is  independent  of  the  hardware  platform,  the 
operating  system,  and  the  programming  language  in  which  the 
service  is  implemented.  (2006,  p.  1) 

The  technology  independent  service  provided  by  one  system  may  be 
subscribed  to  by  any  other  system  with  the  authority  to  do  so.  The  same  service 
may  be  consumed  by  multiple  enterprise  systems.  The  technology  independent 
service,  referred  to  as  “loosely  coupled,”  eliminates  the  need  for  a  direct 
connection  to  every  system  sharing  data.  Alterations  may  be  made  to  the 
underlying  system  without  affecting  the  published  service.  In  this  manner, 
changes  to  the  system  of  record  are  transparent  to  systems  consuming  the  data. 

The  USCG  utilizes  the  ESB  exclusively  for  all  new  connections  between  IT 
systems.  As  legacy  systems  are  updated,  direct  system  interconnections  are 
eliminated  in  favor  of  ESB  topics. 

B.  ENTERPRISE  SYSTEM  DEVELOPMENT  WITHIN  PORTFOLIOS 
1 .  Overview 

The  Project  Management  Institute  (PMI)  discusses  the  relationship 
between  projects,  programs,  and  portfolios: 

A  portfolio  refers  to  a  collection  of  projects  or  programs  and  other 
work  that  are  grouped  together  to  facilitate  effective  management  of 
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that  work  to  meet  strategic  business  objectives.  The  projects  or 
programs  of  the  portfolio  may  not  necessarily  be  interdependent  or 
directly  related.  (PMI,  2008,  p.  8) 

A  program  is  “a  group  of  related  projects  managed  in  a  coordinated  way  to 
obtain  benefits  and  control  not  available  from  managing  them  individually”  (PMI, 
2008,  p.  9).  Thus  a  portfolio  encompasses  programs  which  encompass  projects, 
placing  projects  at  the  lowest  level  of  this  hierarchy.  Not  all  projects  are  a 
member  of  a  program,  but  all  programs  have  subordinate  projects.  Management 
at  the  portfolio  level  is  concerned  with  attaining  strategic  business  goals,  aligning 
efforts  with  organizational  strategies,  and  proper  resource  allocation.  Critical  to 
the  program  definition  is  the  requirement  that  member  projects  are  “related 
through  [a]  common  outcome  or  collective  capability.  If  the  relationship  between 
projects  is  only  that  of  a  shared  client,  seller,  technology,  or  resource,  the  effort 
should  be  managed  as  a  portfolio  of  projects  rather  than  as  a  program”  (PMI, 
2008,  p.10).  Unfortunately,  in  practice  this  clear  hierarchy  and  line  of  authority 
from  portfolio  to  project  is  not  always  present. 

2.  Resource  Concerns 

Central  to  the  idea  of  enterprise  architecture  and  IT  is  a  well  thought  out 
high  level  view  of  a  business  and  its  needs.  In  avoiding  or  eliminating  IT  silos  in 
favor  of  process  oriented  enterprise  solutions,  the  overall  IT  portfolio  must  be 
considered.  Even  if  enterprise  systems  within  the  IT  portfolio  of  a  business  do  not 
logically  interact,  they  affect  one  another  by  their  funding  and  resource 
requirements.  In  order  to  complete  a  major  upgrade  of  one  system,  a  different 
system  may  be  required  to  subsist  for  the  year  on  minimal  funding  and  support. 
Gronau  and  Rohloff  explain,  “From  the  position  of  the  value  within  the  portfolio, 
recommendations  for  future  arrangement  of  the  IT  strategy  are  derived”  (2008, 
p.1077).  No  enterprise  system  exists  in  a  vacuum  and  the  portfolio  view  must  be 
managed  to  prevent  duplication  of  effort  and  ensure  responsible  expenditure  of 
funds,  as  well  as  an  overall  balance  of  systems. 
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3.  Interdependent  System  Development  Complexities 

In  addition  to  resource  concerns,  enterprise  system  interactions  must  be 
considered  at  the  portfolio  level,  preferably  during  system  design  and 
requirements  gathering  phases.  By  avoiding  duplication  of  effort,  the  likelihood 
systems  will  share  data,  or  operate  on  common  data,  is  increased. 

For  systems  under  concurrent  development,  difficulties  are  encountered 
when  attempting  to  coordinate  development  schedules  between  separate 
enterprise  systems.  No  master  schedule  encompassing  the  projects  exists 
because  the  projects  are  otherwise  independent.  Although  the  goal  is  to  loosely 
couple  systems  via  constructs  such  as  the  ESB,  systems  must  articulate  their 
data  requirements  to  one  another.  If  these  requirements  have  been  recognized  at 
the  portfolio  level  during  the  early  stages  of  design,  the  effort  can  easily  be 
scoped  into  the  respective  project  plans.  If  the  need  is  recognized  in  later  stages, 
creation  of  unplanned  ESB  topics  can  force  schedule  slippage.  In  large 
organizations,  a  change  review  board,  or  other  authority,  must  authorize  changes 
to  a  project’s  functionality  and  schedule.  Often,  these  enterprise  systems  have 
separate  review  boards  with  differing  priorities.  It  can  be  challenging  to  compel 
another  program’s  board  to  consider  the  needs  of  your  program.  Furthermore,  for 
unplanned  work,  the  other  system  may  require  you  to  supply  funding  for  the 
effort.  Practically  speaking,  schedules  rarely  align,  requiring  effort  by 
management  at  organizational  levels  above  those  of  the  projects  themselves. 
Organizational  factors  will  then  determine  work  priority. 

C.  DEVELOPMENT  OF  COMPLEX  SOFTWARE  SYSTEMS 

1 .  Overview 

Design  and  development  of  complex  software  systems  involves  actors  at 
all  levels  of  an  organization.  General  discussion  in  this  thesis  is  limited  to 
enterprise  systems  development  within  large  organizations,  where  stakeholders 
may  or  may  not  be  internal  to  the  organization,  but  they  are  distinct  from  the 
business  entities  responsible  for  project  development.  Furthermore,  the  focus  of 
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discussion  is  the  portfolio,  program,  or  organizational  view,  rather  than  the 
project  as  an  independent  entity.  Envisioning  the  portfolio  in  which  a  project  is 
developed  as  a  series  of  concentric  rings  is  helpful  in  illustrating  variables 
influencing  single  project  development  (Figure  2). 
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Figure  2.  Managing  Complex  Software  Projects:  Single  Project  View 


The  project  is  affected  by  project  manager  decisions,  its  own 
characteristics,  and  organizational  factors  (Oorschot  et  al.,  2013).  Of  specific 
interest  is  the  interaction  of  the  organizational  realities  ring  with  the  other 
variables,  and  how  the  development  and  performance  of  other  enterprise 
systems  within  the  portfolio  can  affect  other  projects.  Figure  3  illustrates  how 
multiple  projects  often  interact  with  each  other,  all  affected  by  organizational 
realities.  Large  organizations  may  have  hundreds  of  projects  within  an  enterprise 
portfolio.  A  high  level  overview  of  each  ring  is  provided  in  order  to  create  a 
framework  for  analyzing  interaction  between  variables. 
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Figure  3.  Managing  Complex  Software  Projects:  Portfolio  View 


2.  Project  Manager  Decision  Space 

Although  other  factors  also  affect  the  success  or  failure  of  IT  projects, 
Verner,  Sampson,  and  Cerpa  (2008),  and  Nelson  (2007)  agree  project 
management  plays  a  critical  role.  Nelson  states,  “After  studying  the  infamous 
failures... it  becomes  apparent  that  failure  is  seldom  a  result  of  chance.  Instead,  it 
is  rooted  in  one,  or  a  series  of,  misstep(s)  by  project  managers”  (2007,  p.  67). 

The  role  of  the  project  manager  is  well  defined  in  the  project  management 
body  of  knowledge  (PMBOK)  as  established  by  the  PMI.  A  project  manager  has 
responsibilities  to  both  the  internal  team  and  external  organization  (Satzinger, 
Jackson,  &  Bird,  2009). 

3.  Project  Characteristics 

Characteristics  of  the  project  itself  are  straightforward,  though  not  always 
correctly  identified  early  in  the  design  process.  As  defined  by  the  PMI,  a  “project 
is  a  temporary  endeavor  undertaken  to  create  a  unique  product,  service,  or 
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result”  (2008,  p.  5).  In  the  enterprise  information  systems  context,  projects 
typically  require  hardware,  software,  and  network  infrastructure.  Depending  on 
complexity,  project  duration  may  range  from  several  weeks  to  several  years, 
costing  from  thousands  to  billions  of  dollars.  The  magnitude  and  complexity  of  a 
proposed  system  also  impacts  time  required  for  development.  The  goals  or 
expected  functionality  of  the  information  system  are  represented  here.  A 
common  construct  describes  the  relation  of  project  characteristics  with  other 
factors.  The  construct,  with  small  variation,  is  referred  to  as  the  Golden  Triangle 
(Gardiner  &  Stewart,  2000),  the  Iron  Triangle  (Atkinson,  Crawford,  &  Ward,  2006) 
or  the  Triple  Constraint  (Schwalbe,  2006)  and  one  representation  is  shown  in 
Figure  4.  In  this  representation,  quality  is  implied  by  the  interaction  of  the  three 
sides  of  the  triangle.  In  other  representations,  quality  may  be  placed  on  a  side, 
with  cost  in  the  middle.  Time  and  cost  are  self-explanatory,  and  scope  refers  to 
the  desired  functionality  of  the  system.  Although  this  representation  is  very 
simplistic,  it  reinforces  the  idea  that  only  two  of  the  three  sides  may  be  altered  at 
any  one  time,  with  the  impact  of  alterations  shown  in  the  third  side.  If  schedule 
time  and  cost  are  reduced,  the  scope  of  the  project  must  decrease.  If  increased 
scope  is  desired  while  holding  schedule  time  constant,  cost  will  increase  (due  to 
expanding  the  development  team,  etc.).  It  should  be  noted  that  although 
alterations  to  one  side  or  another  may  be  desired,  the  alteration  may  not  be 
possible  for  the  organization  to  implement  due  to  capacity  constraints. 
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Scope 


Figure  4.  Project  Management  Triangle  (from  Tutorialspoint,  n.d.) 

4.  Organizational  Realities  (Factors) 

Organizational  factors  permeate  and  influence  every  project  as  well  as  the 
higher  portfolio.  Ross  notes,  “The  policies  and  technical  choices  for  developing  IT 
capabilities  must  reflect  organizational  realities  and  thus  inevitably  require 
tradeoffs”  (2003,  p.  3).  True  alignment  of  business  and  IT  objectives  is  difficult  to 
achieve,  as  indicated  by  Sjoberg,  Odberg,  and  Warlo: 

Large  private  enterprises  and  government  agencies  generally  have 
a  comprehensive  portfolio  of  interdependent  information  systems.  A 
major  challenge  faced  by  these  organizations  is  how  to  control  the 
increasing  complexity  and  the  associated  costs  of  such  systems  as 
the  portfolio  evolves.  Typically,  the  number  and  size  of  the  systems 
and  the  components  of  the  individual  systems  increases  over  time, 
as  well  as  the  number  of  relationships  between  these  systems  and 
components.  The  continuous  change  in  the  nature  of  the  business 
and  often  the  increased  complexity  of  the  domain  lead  to  more 
complex  system  requirements  and  information  models,  and  the 
increased  functionality  of  the  systems.  (2010,  p.  71) 

Even  when  business  and  IT  objectives  finally  align,  the  business  itself  changes, 
or  the  information  systems  require  increased  functionality  or  replacement  of 
outdated  technology  standards  with  current  ones  in  order  to  maintain 
compatibility  with  other  networked  systems.  As  mentioned  in  the  “Rationale  for 
Enterprise  IT,”  and  supported  by  Ross,  “The  objective  is  to  get  to  the  point  where 
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IT  capabilities  shape  business  strategy  while  business  strategy  shapes  IT 
capabilities  in  response  to  changing  market  conditions  and  organizational 
realities”  (2003,  p.  3). 

D.  TYING  IT  ALL  TOGETHER:  ORGANIZATIONAL  FACTOR 

INTERDEPENDENCIES 

1 .  Overview 

As  introduced  above,  organizational  factors  are  dynamic  and  shape  the 
environment  within  which  IT  portfolio  development  takes  place.  This  concept  will 
be  thoroughly  explored  because  it  is  central  to  understanding  the  effect  programs 
and  projects  may  have  upon  one  another  within  a  portfolio.  Organizational  factors 
can  be  described  as  either  explicit  or  implicit  (Oorschot  et  al.,  2013). 

2.  Explicit  Factors 

Explicit  organizational  factors  are  typically  directly  stated  in  a  formal 
business  plan,  goal,  or  vision  statement.  They  are  also  stated  in  official  policies, 
standard  operating  procedures,  and  guidelines.  IT  system  projects  based  on 
explicit  organizational  factors  may  be  in  response  to  the  competitive  advantage 
of  another  company,  or  created  in  an  effort  to  gain  competitive  advantage.  Legal 
and  government  regulations  and  budgetary  constraints  are  explicit  factors. 
Explicit  measurements  for  IT  systems  include  net  present  value,  internal  rate  of 
return,  and  economic  value  added.  If  systems  are  expected  to  generate  profits, 
explicit  factors  may  include  marketing,  sales,  and  profitability  factors.  In  other 
cases,  the  system  may  indirectly  support  the  business,  such  as  human  resources 
systems,  customer  databases,  and  ecommerce  systems.  The  ecommerce 
system,  for  example,  does  not  increase  sales  directly,  but  enables  sales  over  the 
internet  in  order  to  broaden  the  company’s  potential  customer  base. 

According  to  PMI,  “Organizational  structure  is  an  enterprise  environmental 
factor  which  can  affect  the  availability  of  resources  and  influence  how  projects 
are  conducted.  Organizational  structures  range  from  functional  to  projectized, 

with  a  variety  of  matrix  structures  between  them”  (2008,  p.  28).  Organizational 
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structure  delineates  explicit  lines  of  authority  for  programs  and  projects.  A 
functional  organization  is  the  traditional  hierarchical  representation  where 
employees  have  one  superior,  and  departments  are  organized  by  function  under 
a  functional  manager  or  vice  president.  Examples  of  functional  departments  are 
human  resources,  production,  engineering,  etc.  Departments  typically  work 
independently  of  each  other.  In  a  matrixed  structure,  an  employee  will  often 
report  to  both  a  functional  manager  and  a  project  manager.  The  employee  is 
assigned  to  work  on  a  project  but  is  still  “owned”  by  the  functional  manager.  If  a 
project  has  no  work  for  the  employee  on  a  given  day  the  functional  manager  can 
reassign  them  as  needed.  A  truly  project-oriented  structure  grants  the  project 
manager  a  great  deal  of  authority,  but  can  be  inefficient.  In  this  model,  the  project 
manager  has  a  diverse  staff  assigned  to  them  for  the  duration  of  the  project.  The 
project  funds  the  staff,  regardless  of  whether  there  is  immediate  work  to  be  done 
by  a  particular  member  (Schwalbe,  2006).  Table  1  summarizes  the  project 
characteristics  associated  with  the  different  organization  structures. 


Organization 

Matrix 

OirULlUIc 

Project 

Characteristics''"*. 

Functional 

Weak  Matrix 

Balanced  Matrix 

Strong  Matrix 

Projectized 

Project  Manager's 
Authority 

Little  or  None 

Limited 

Low  to 
Moderate 

Moderate 
to  High 

High  to 
Almost  Total 

Resource 

Availability 

Little  or  None 

Limited 

Low  to 

Moderate 

Moderate 
to  High 

High  to 
Almost  Total 

Who  controls  the 
project  budget 

Functional 

Manager 

Functional 

Manager 

Mixed 

Project 

Manager 

Project 

Manager 

Project  Manager's 
Role 

Part-time 

Part-time 

Full-time 

Full-time 

Full-time 

Project  Management 
Administrative  Staff 

Part-time 

Part-time 

Part-time 

Full-time 

Full-time 

Table  1.  Organizational  Influences  on  Projects  (from  PMI, 

2008,  p.  28) 
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3.  Implicit  Factors 

As  addressed  here,  implicit  means  “implied,  rather  than  expressly  stated” 
(dictionary.com,  n.d.).  Due  to  their  nature,  implicit  factors  may  not  be  apparent, 
depend  on  individual  interpretation,  and  can  be  dynamic.  Prior  literature  has 
demonstrated  that  implicit  factors  can  have  a  significant  effect  on  the 
implementation  and  success  of  IT  projects.  A  synthesis  of  the  literature  on 
information  systems  project  management,  and  management  of  research  and 
design  organization  portfolios,  reveals  three  primary  themes  in  the  category  of 
implicit  factors: 

•  Capacity 

•  Control 

•  Funding  Priorities 

The  three  implicit  factor  areas  are  explored  in-depth  in  the  following  sections. 

a.  Capacity 

Capacity  refers  to  the  ability  of  an  organization  to  complete  work.  At  full 
capacity  an  organization  has  exactly  the  appropriate  personnel  and  resources 
available  to  perform  all  work,  according  to  the  various  program  and  project 
schedules.  In  reality,  the  operation  of  a  large  organization  is  too  dynamic  to  attain 
or  maintain  full  capacity  in  this  sense.  Chuan  and  Raghavan  state,  “Conflicting 
resource  constraints  between  departments  translate  into  business  risk”  (2004,  pp 
21).  Capacity  and  funding  priorities  are  similar  in  that  they  truly  become  the 
object  of  scrutiny  when  there  are  insufficient  resources  to  complete  all  work.  If 
too  much  work  has  been  accepted,  or  capacity  has  been  reduced  due  to 
turnover,  reduction  (or  lack)  of  funds,  or  other  loss  of  resources,  the  programs 
and  projects  within  a  portfolio  will  be  prioritized. 

Capacity  can  be  visible,  or  hidden.  An  example  of  visible  capacity  is  seen 
in  the  airline  industry.  The  airline  knows  the  explicit  capacity  of  an  airplane,  and 
chooses  to  overbook  the  flight.  They  know  how  many  people  check  in  for  the 
flight,  and  before  boarding  takes  place,  they  know  if  the  plane  has  exceeded 
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capacity.  In  this  event,  they  offer  incentives  to  reduce  the  number  of  passengers 
to  that  which  the  plane  can  carry.  The  industry  has  determined  this  approach  to 
be  the  most  cost  effective  in  the  long  run,  and  the  process  is  deliberate. 
Unfortunately,  businesses  with  large  IT  portfolios  engaging  in  complex  system 
development  have  no  such  method  to  gauge  excess  capacity.  It  is  hidden  in  the 
sense  that  it  cannot  be  objectively  determined  at  an  arbitrarily  chosen  point  in 
time.  In  system  development,  the  concept  of  exceeding  capacity  is  associated 
with  elongating  schedules,  increasing  cost,  and  personnel  issues.  As  Sjoberg  et 
al.,  note,  “The  greater  complexity  of  the  software  portfolio  leads  to  a  higher  cost 
of  developing  new  systems  and  maintaining  existing  ones,  a  reduced  business 
agility,  a  longer  time-to-market,  and  an  increased  dependence  on  highly  skilled 
people”  (2010,  p.  71). 

Adding  to  the  uncertainty  of  the  capacity  issue  is  the  desire  of  many 
organizations  to  optimize  operations  through  the  elimination  of  organizational 
slack.  Bourgeois  defined  organizational  slack  as 

...that  cushion  of  actual  or  potential  resources  which  allows  an 
organization  to  adapt  successfully  to  internal  pressures  for 
adjustment  or  to  external  pressures  for  change  in  policy  as  well  as 
to  initiate  changes  in  strategy  with  respect  to  the  external 
environment.  (1981,  p.  30) 

Bourgeois  argued  that  although  cutting  apparent  organizational  slack  could 
achieve  short-term  efficiency,  it  was  detrimental  over  time  (1981).  Keegan  and 
Turner  present  the  opposing  view:  “Opponents  of  slack  claim  that  it  promotes 
undisciplined  investment  in  new  developments  and  new  products  and  services 
that  show  poor  potential  to  generate  economic  benefits”  (2002,  p.  369).  As 
mentioned,  however,  in  the  context  of  complex  IT  portfolio  development  and 
management,  excess  capacity  is  dynamic  and  difficult  to  quantify.  From  a 
personnel  perspective,  in  a  project-based  firm  it  is  not  practical  to  lay  off  skilled 
developers  following  project  completion,  expecting  they  will  return  to  the 
company  for  the  next  project.  In  a  matrix  based  organization,  one  project  may 
reserve  a  specialist  who  is  reassigned  to  a  higher  priority  project  at  the  last 
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moment,  jeopardizing  the  schedule  of  the  original  project.  For  a  company 
attempting  slack  minimization,  Goncalves,  Mendes,  and  Resende  note  “the 
allocation  of  scarce  resources  then  becomes  a  major  objective  of  the  problem 
and  several  compromises  have  to  be  made  to  solve  the  problem  to  the  desired 
level  of  near-optimality”  (2004,  p.  1171).  Put  another  way,  projects  in  the  portfolio 
may  suffer  due  to  excessive  focus  on  slack  minimization. 

A  common  capacity  problem  often  seen  in  businesses  which  have 
minimized  organizational  slack  is  firefighting.  In  the  IT  portfolio  context,  the  more 
complex  a  system  development  project  is,  the  more  likely  it  will  experience 
unforeseen  problems  (Sjoberg  et  al.,  2010).  A  “fire”  results  when  a  project 
experiences  such  a  problem,  requiring  assistance  from  resources  external  to  the 
team.  In  the  “optimized”  organization,  external  resources  must  be  pulled  from 
other  teams,  thereby  putting  their  project  schedules  at  risk.  This,  in  turn,  may 
cause  a  “fire”  in  that  project,  and  the  process  propagates.  Programs  of  sufficient 
size  may  experience  local  firefighting  within  the  program,  as  one  sub-team 
cannibalizes  another.  The  immediate  effects  of  firefighting  are  many: 

Firefighting  imposes  numerous  costs... Introduction  dates  are  often 
slipped,  reducing  the  chance  of  market  success;  engineers  and 
managers  sometimes  work  extraordinary  hours,  leading  to  fatigue, 
burnout,  turnover,  and  increasing  the  chance  of  further  errors;  and 
additional  people  are  often  added  to  the  project,  thus  requiring 
additional  expense.  (Repenning,  2001,  p.  286) 

From  the  portfolio  management  perspective,  firefighting  is  a  self-propagating 
cycle  (Bohn  &  Jaikumar,  2000;  Repenning,  2001). 

Bohn  and  Jaikumar  feel  firefighting  is  best  described  as  a  syndrome, 
comprised  of  the  following  linked  elements  (2000,  p.  4): 

•  Too  many  problems,  not  enough  time  to  solve  them  all. 

•  Incomplete  solutions 

•  Recurring  and  cascading  problems 

•  Urgency  supersedes  importance 
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•  Preemption  of  one  problem  solving  effort  by  another 

•  Performance  drop 

Concerning  the  elements,  they  note:  “We  consider  any  organization  that 
exhibits  three  or  more  of  these  elements  to  be  doing  firefighting,  and  if  they  are 
chronic  it  has  the  firefighting  syndrome”  (Bohn  &  Jaikumar,  2000,  p.  5).  In  such 
an  environment,  a  fundamentally  troubled  project  may  be  misinterpreted  as 
simply  having  capacity  issues.  An  otherwise  healthy  project  may  be  perceived  as 
problematic  due  to  the  symptoms  of  firefighting  without  an  understanding  of  the 
true  cause.  They  describe  the  self-propagating  nature  of  the  syndrome: 

...there  is  a  significantly  worse  situation  that  applies  to  many 
organizations,  especially  those  where  problem  solving  is  inherently 
difficult.  In  these  cases,  the  pressure  of  a  backlog  of  unsolved 
problems  leads  engineers  to  solve  problems  not  just  inefficiently, 
but  badly.  As  a  result,  each  problem  supposedly  solved  has  a 
chance  of  creating  a  new  problem,  and  sometimes  more  than  one. 

(Bohn  &  Jaikumar,  2000,  p.  16) 

When  this  happens,  projects  become  more  susceptible  to  contagion  from  other 
programs  within  the  portfolio. 

b.  Control 

In  complex  organizations,  control  may  be  wielded  by  individuals  or  groups 
at  varying  levels  of  hierarchy.  At  higher  levels,  controllers  influence  IT 
architecture,  organizational  goals  and  portfolio  strategy.  At  the  middle  level, 
controllers  influence  project  development  schedules,  distribution  of  project  funds, 
and  prioritization.  Lower  levels  control  system  quality  and  implementation. 
Controllers  may  or  may  not  be  explicitly  designated  and  may  have  individual 
interests  in  certain  programs  or  projects.  Implicit  control  brokers  may  be  informal 
advisors  to  explicit  decision  makers,  or  may  have  influence  for  a  variety  of 
reasons  including  interpersonal  relationships,  rank,  or  previous  position  within  the 
organization. 
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Much  of  the  research  in  organizational  control  theory  is  based  on  the  work 
of  Ouchi  and  extended  by  others,  prominently  Laurie  Kirsch  and  various 
collaborators.  Rustagi,  King,  and  Kirsch  elaborate  on  the  difference  between 
formal  and  informal  control: 

Scholars  investigating  control  often  make  a  distinction  between 
formal  and  informal  controls,  noting  that  mechanisms  used  to 
exercise  formal  control  are  documented,  while  mechanisms  of 
informal  control  are  generally  implicit  (Kirsch  2004).  Thus,  written 
project  plans,  testing  procedures,  and  job  descriptions  are 
mechanisms  of  formal  control,  whereas  peer  pressure,  influence, 
and  social  events  constitute  informal  control  mechanisms.  (2008, 

pp.  128) 

Two  prominent  modes  of  formal  control  are  behavior  and  outcome 
(Eisenhardt,  1985;  Kirsch,  Sambamurthy,  Ko,  &  Purvis,  2002;  Kirsch,  2004; 
Ouchi,  1979,  1980).  Behavioral  control  involves  following  appropriate  rules  and 
procedures  in  performing  pre-specified  tasks.  Performance  is  evaluated  based 
on  the  extent  to  which  the  procedures  were  adhered  to  (Boss,  S.,  Kirsch, 
Angermeier,  Shingler,  &  Boss,  R.,  2009;  Kirsch  et  al.,  2002).  Outcome  control 
shifts  emphasis  to  achievement  of  a  stated  goal,  regardless  of  the  process 
followed  to  achieve  it.  Successful  performance  is  related  to  the  extent  the  goals 
were  met  (Boss  et  al.  2009;  Kirsch  et  al.  2002;  Rustagi  et  al.,  2008).  Formal 
control  is  often  explicitly  exercised  according  to  the  organizational  structure  of  a 
business.  In  a  functional  organization,  a  manager  exerts  control  on  an  employee. 
In  a  matrixed  organization,  an  employee’s  manager,  or  project  manager  exert 
control.  In  the  project-oriented  organization  the  project  manager  exerts  the 
majority  of  formal  control  on  team  members.  In  all  cases  varying  amounts  of 
formal  control  are  exercised  in  the  hierarchy,  or  in  the  armed  forces  by  the  chain 
of  command. 

The  method  of  informal  control  relevant  to  this  study  is  clan  control.  A  clan 
was  defined  by  Ouchi  “as  a  group  of  individuals  who  are  dependent  on  each 
other,  and  who  display  a  great  deal  of  goal  congruence,  shared  values,  and 
norms,  discipline  toward  their  work,  and  ‘solidarity’  and  ‘regularity’  in  their 
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relations  with  each  other”  (Kirsch,  Ko,  &  Haney,  2010,  p.  470).  Clan  control,  then, 
is  the  theory  that  a  clan  exercises  control  over  its  members  via  socially  accepted 
behavior  within  the  clan  norms  (Kirsch  et  al. ,  2010).  Kirsch  et  al. ,  also  note  “The 
mere  existence  of  shared  norms,  values,  vision,  or  agreed-upon  behaviors  does 
not  indicate  clan  control;  however,  when  actual  behavior  is  influenced  by  those 
shared  norms,  values,  vision,  or  agreed-upon  behaviors,  clan  control  is 
operating”  (2010,  pp  471).  An  interesting  question  may  be  asked  when 
investigating  implicit  control  within  an  organization:  Which  clan  is  an  individual 
conforming  to  when  behaving  in  a  certain  way?  Is  the  clan  the  team,  the 
department,  or  some  other  group  an  individual  may  consider  themselves  a  part 
of?  Rutner  examines  the  emotional  dissonance  felt  by  IT  professionals  who  are 
regularly  expected  to  interface  with  both  IT  colleagues  and  workers  in  other 
functional  areas  who  often  display  different  occupational  norms  (2008).  This 
dissonance  is  amplified  in  DOD  and  other  government  agencies  where  civilian 
contractors  often  work  with  members  of  the  uniformed  services.  To  which  norms 
(clan)  would  an  individual  conform? 

Further  distinction  in  clan  control  focuses  on  input  mechanisms  and 
targets  (Cardinal,  2001 ;  Cardinal,  Sitkin,  &  Long,  2004)  as  well  as  the  role  of  clan 
control  and  behavior.  According  to  Kirsch  et  al.,  the  latter  area  investigates  “the 
role  of  shared  norms,  values,  and  vision  in  guiding  and  influencing  behaviors. 
Researchers  who  adopt  this  latter  perspective  tend  to  focus  on  the  role  of  clan 
control  in  motivating  specific  behaviors  of  individuals  in  existing  work  groups” 
(2010,  p.  471).  Determining  an  individual’s  perceived  clan  affiliation  is  beneficial 
in  determining  the  motivation  behind  an  action.  A  seemingly  nonsensical  action 
may  make  sense  when  viewed  in  the  appropriate  clan  context,  which  may  not  be 
obvious. 

Different  combinations  of  formal  and  informal  control  have  been  observed 
operating  individually,  or  in  conjunction,  in  different  organizations.  Cardinal, 
(2001),  Cardinal  et  al.  (2004)  and  Kirsch  (1997,  2004)  argue  clan  control  can 
complement  formal  control,  and  they  document  informal  control  use  in  formal 
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business  settings.  “In  the  context  of  teams,  it  is  possible  to  observe  both  lateral 
(peer  to  peer)  control  and  hierarchical  (manager  to  subordinate)  control”  (Kirsch 
et  al.,  2010,  p.  471).  Finally,  Kirsch  et  al.  (2010)  argue  control  types  may  change 
during  IT  projects  due  to  the  evolving  relationship  between  controller  and 
controlee.  Choudhury  and  Sabherwal  (2003)  concur,  observing  outcome  controls 
dominate  the  initial  phases  of  a  project,  with  behavioral  controls  added  later. 

c.  Funding  Priorities 

Funding  priorities  are  often  not  directly  stated  (or  known)  until  necessary. 
Although  a  portfolio  is  seldom  fully  funded,  when  this  occurs  there  is  little  need  to 
discuss  which  programs  or  projects  are  more  important  than  others.  In  reality, 
budgets  are  often  allocated  yearly  while  projects  may  span  multiple  years.  During 
long  term  development,  discovery  of  new  requirements  or  unforeseen  difficulties 
can  cause  projects  to  overrun  initial  projections,  which  in  turn  causes  a  shortage 
of  funds  at  the  portfolio  level  (Oorschot  et  al.,  2013).  When  this  occurs  in  an 
already  leanly  funded  portfolio,  priority  becomes  critical.  Indeed,  this  discussion 
is  often  contentious  and  confrontational  when  decided  by  committee  rather  than 
a  single  individual. 

Prioritization  in  large  organizations  is  problematic.  Chun  and  Rainey 
(2005)  address  the  issue  in  reference  to  US  federal  agencies: 

Priority  goal  ambiguity  refers  to  the  level  of  interpretive  leeway  in 
deciding  on  priorities  among  multiple  goals.  To  indicate  priorities 
means  to  make  decisions  about  which  goals  should  take 
precedence  over  others  at  a  given  time,  or  to  form  a  goal  hierarchy 
in  which  the  goals  are  vertically  arranged  through  means-ends 
relationships  (Richards  1986).  The  presence  of  multiple  goals 
without  any  hierarchical  arrangement  and  prioritization  leaves  much 
room  for  interpretation  of  such  priorities  and  about  which  goals  take 
precedence,  (p.  4) 

Although  Chun  and  Rainey  use  priority  goal  ambiguity  as  an  empirical  measure, 
the  idea  illustrates  that  priority  determination  becomes  more  complex  as  more 
goals  or  projects  are  considered.  The  statement  on  the  consequence  of  the 
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absence  of  prioritization  is  critical.  With  too  much  room  for  interpretation  of 
priority,  personal  preference,  incompetence,  and  other  informal  or  social 
concerns  may  become  the  basis  for  goal  ranking,  rather  than  importance  to  the 
overall  organization. 

A  large  organization  may  have  hundreds  of  smaller  systems  within  the  IT 
portfolio.  As  Jung  notes,  partially  based  on  the  work  of  Chun  and  Rainey, 
organization  size  and  complexity  compounds  priority  ambiguity  issues  and  can 
increase  the  number  of  goal  conflicts: 

When  public  organizations  have  more  goals,  it  will  be  more  difficult 
to  clearly  set  priorities  among  them,  and  thereby  some  type  of 
organizational  goal  ambiguity  (e.g.,  priority  ambiguity)  will  be 
increased  (Chun  and  Rainey  2005a).  In  addition,  the  presence  of 
more  goals  can  bring  more  occurrences  of  goal  conflict.  In  other 
words,  in  public  agencies  with  multiple  goals,  the  achievement  of 
some  goals  can  be  complicated  or  hindered  by  the  achievement  of 
other  goals.  (2013,  p.  5) 

An  explicit  method  of  clear  prioritization  would  be  ideal.  Bardhan,  Bagchi, 
and  Sougstad  proposed  a  portfolio  valuation  and  ranking  system  based  on  real 
options,  although  they  acknowledge  “complexities  of  IT  projects  along  with  the 
effect  of  project  interdependencies  raise  several  challenges  in  applying  real 
options  for  prioritization  of  IT  investments”  (2004,  p.  33).  Several  other  articles 
propose  alternate  models,  including  the  “balanced  scorecard”  (Hu  &  Huang, 
2006,  p.  5),  applications  of  the  “dynamic  capabilities  perspective”  (Chen  et  al., 
2008,  p.  366),  and  the  “IT/Business  Alignment  Maturity”  model  (Luftman,  2003,  p. 
9).  All  proponents  acknowledge  the  complex  challenge  involved,  and  emphasize 
business  and  IT  alignment  is  a  journey,  not  a  state  (Hu  &  Huang,  2006). 

Bardhan,  Kauffman,  and  Naranpanawe  further  reinforce  the  idea  of  goal 
conflict  and  the  challenge  of  prioritization: 

IT  budgets  of  many  large  corporations  consist  of  several  hundreds 
of  IT  projects  and  not  just  a  handful.  They  all  are  simultaneously 
vying  for  funding  approval.  As  a  result,  it  is  a  significant  challenge 
to  identify  and  select  those  projects  that  are  properly  aligned  with 
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the  firm’s  business  strategy  going  into  the  future  and  then  to 
implement  them  in  a  proper  sequence  in  order  to  yield  the  maximal 
value  for  the  organization.  (201 0,  p.  2:2) 

Not  only  is  prioritization  complex,  project  managers  have  a  vested  interest 
in  seeing  their  project  funded,  and  present  compelling  value  arguments.  With 
potentially  hundreds  of  worthy  IT  projects  to  prioritize,  how  do  decision  makers 
determine  which  ones  best  align  with  business  objectives?  Substantial  research 
has  been  performed  regarding  business  and  IT  alignment  from  a  portfolio  view. 
Hu  and  Huang  explain  “Studies  show  that  the  lack  of  alignment  between  IT  and 
business  strategies  is  one  of  the  main  reasons  why  firms  fail  to  realize  the  full 
potential  of  their  IT  investments”  (2006,  p.  3).  Alignment  of  business  and  IT  goals 
helps  decision  makers  not  only  prioritize  projects,  but  provides  motivation  to 
better  support  them.  “IS  development  projects  may  take  too  much  time,  or  even 
fail,  if  [senior  management]  commitment  is  erratic”  (Newman  &  Sabherwal,  1996, 
p.  24)  and  “commitment  is  clearly  important  to  the  success  of  IS  development 
projects”  (Newman  &  Sabherwal,  1996,  p.  23).  Not  only  should  decision  makers 
establish  clear  funding  priorities,  they  should  communicate  the  priorities,  in 
conjunction  with  the  business  strategies,  to  all  levels  of  the  organization. 

d.  Interdependencies  of  Implicit  and  Explicit  Factors 

Implicit  and  explicit  factors  are  highly  interdependent  and  interact  both 
laterally  between  departments  and  organizations,  and  vertically,  throughout  an 
organization’s  hierarchy  (which  is  itself  also  an  explicit  factor).  As  explicit  vertical 
hierarchy  increases,  so  does  the  potential  for  implicit  factor  influence.  A  classic 
example  is  telling  the  first  person  in  a  long  line  a  simple  fact  and  having  them 
relay  it  to  the  next  person,  repeating  this  process  until  the  end  of  the  line.  When 
the  last  person  relays  what  they  were  told,  there  is  a  good  chance  it  has  changed 
from  the  original  message.  In  the  case  of  explicit  organizational  hierarchy,  the 
desire  to  please  your  superior  is  an  additional  factor.  Implicit  control  and  capacity 
concerns  may  enter  at  any  level.  Lateral  interaction  includes  firefighting 
syndrome,  as  well  as  concerns  regarding  clan  control  between  groups.  Sinha 
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and  Van  de  Ven  (2005)  conceptualize  work  between  and  within  organizations  as 
shown  in  Figure  5  and  this  also  serves  as  an  excellent  framework  for  this  study. 
While  the  authors  focus  on  work,  the  graphic  and  concepts  apply  extremely  well 
in  illustrating  program  and  project  complexity  and  the  effect  of  organizational 
factors,  both  within  an  organization’s  IT  portfolio,  and  across  departments  and 
related  organizations. 


Conceptualizing  Work  Design  Problems:  Within  and 
Between  Organizations 

Many 


Hierarchical  levels 
(Vertical  division 
of  work  within  an 
organizational  unit) 


One 

One  Organizations  Many 

(Horizontal  division  of  work  between 
organizational  units  of  one  or  more  firms) 

Figure  5.  Conceptualizing  Work  Design  Problems  (from  Sinha,  &  Van  de 

Ven,  2005,  p.  390) 
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In  Figure  5,  the  vertical  axis  refers  to  work  within  an  organizational 
hierarchy.  Sinha  and  Van  de  Ven  state  “The  resources,  knowledge,  and  authority 
of  a  work  system  may  be  contained  within  one  level  of  an  organization,  or  it  may 
be  divided  among  many  hierarchical  levels”  (2005,  p.  390).  In  complex  IT 
portfolios,  explicit  organizational  factors  typically  operate  vertically,  influenced  by 
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implicit  factors.  Resources  are  assigned  in  the  form  of  funding,  authority  is 
assigned  and  derived  from  regulations,  plans,  and  goals,  and  organizational 
knowledge  is  passed  down.  The  horizontal  axis  illustrates  how  “the  work  system 
may  be  distributed  across  many  organizational  units  of  one  or  many  firms,  where 
each  provides  a  component  or  module  for  an  interorganizational  network”  (Sinha 
&  Van  de  Ven,  2005,  p.  390).  In  the  language  of  IT  portfolios,  projects  which  are 
members  of  programs  are  often  developed  concurrently  across  lateral 
departments,  or  by  similar  departments  in  different  organizations.  Concurrent 
development  is  enabled  by  many  object-oriented  methodologies.  Object 
definition  and  division  of  work  can  be  difficult.  Movement  along  the  diagonal  of 
Figure  5  represents  the  space  where  alignment  of  business  goals  and  IT  should 
take  place.  Organizational  factors  permeate  the  entire  space. 

Sinha  and  Van  de  Ven  articulate  three  problems  in  the  figure,  which  also 
apply  to  IT  portfolio  development.  The  modularity  problem  addresses  the 
difficulty  of  dividing  work  between  lateral  departments  or  organizational  units.  At 
what  point  might  outsourcing  or  subcontracting  be  considered  when  undertaking 
large  program  development?  Where  are  the  logical  program  divisions  which 
would  allow  concurrent  development  among  diverse  entities?  The  hierarchical 
problem  involves  vertical  division  of  responsibilities  and  authority.  Often  a 
program  manager  is  at  a  higher  hierarchical  level  than  the  project  manager.  The 
network  problem  is  the  most  complex  and  the  most  problematic,  created  by  the 
interaction  of  the  previous  two  problems.  Sinha  and  Van  de  Ven  describe  the 
network  problem: 

When  combining  the  two  dimensions  shown  in  Figure  [5],  we  have 
a  hierarchically  differentiated  work  system  consisting  of 
interdependent  modules  that  are  performed  by  different 
organizational  units  in  the  work  system  network.  The  complex 
network  problem  represents  the  interaction  effects  of  the  modularity 
and  hierarchy  problems  just  discussed  on  coordinating  work  within 
and  between  organizations.  (2005,  p.  394) 

In  this  context,  the  interaction  possibilities  of  organizational  factors  on  the  IT 

portfolio  are  evident.  It  is  also  here  where  contagion  may  enter. 
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E.  THE  CONTAGION  EFFECT 

Research  regarding  the  contagion  effect  is  well  established  in  financial 
literature,  although  not  directly  found  in  IT  portfolio  management  literature.  The 
firefighting  syndrome  as  described  by  Bohn  and  Jaikumar  can  precede  contagion 
(2000)  and  contribute  to  its  propagation.  The  author  proposes  a  contagion  effect 
can  spread  from  one  problematic  program  or  project  within  a  portfolio  to  disrupt 
otherwise  healthy  projects,  and  supports  this  with  a  case  study  of  two  enterprise 
USCG  IT  systems.  Parallels  can  be  drawn  between  the  spread  of  contagion  in 
financial  systems  and  the  effect  interconnected  enterprise  systems  may  cause 
via  the  complex  network  problem  presented  above,  propagated  by  organizational 
factors. 

One  theory  is  that  small  shocks,  which  initially  affect  only  a  few 
institutions  or  a  particular  region  of  the  economy,  spread  by 
contagion  to  the  rest  of  the  financial  sector  and  then  infect  the 
larger  economy... When  one  region  suffers  a  bank  crisis,  the  other 
regions  suffer  a  loss  because  their  claims  on  the  troubled  region  fall 
in  value.  If  this  spillover  effect  is  strong  enough,  it  can  cause  a 
crisis  in  the  adjacent  regions.  In  extreme  cases,  the  crisis  passes 
from  region  to  region  and  becomes  a  contagion.  (Allen  &  Gale, 

2000,  p.  2) 

The  analogous  situation  in  an  IT  portfolio  refers  to  either  a  program  with 
interconnected  projects,  or  simply  interconnected  projects,  whether  the 
interconnections  are  physical,  operational,  or  implicit.  The  projects  could  be 
developed  within  one  organization,  or  several.  Perturbation  to  an  aspect  of  the 
program  can  cause  similar  perturbations  to  the  subordinate  or  connected 
projects.  For  example,  a  capability  shortage  to  one  project  could  affect 
completion  of  a  component  which  the  subordinate  project  requires  in  order  to 
perform  development.  The  schedule  of  the  subordinate  project  is  affected 
because  it  is  unable  to  begin  development  in  a  timely  manner.  In  another 
example,  functionality  in  the  parent  program  could  be  curtailed  due  to  funding 
priorities,  affecting  schedule  and  functionality  in  interconnected  programs.  A 
series  of  such  shocks  to  the  program  could  eventually  become  a  contagion  from 
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which  the  subordinate  programs  cannot  recover.  As  noted  by  Sinha  and  Van  de 
Ven,  (2005)  when  the  number  of  organizations  and  levels  of  hierarchy  increase, 
so  does  the  complexity  of  the  problem,  and  in  the  IT  context,  the  magnitude  and 
breadth  of  the  impact  of  the  contagion. 

Another  dissimilar  yet  complex  operation  from  which  parallels  can  be 
drawn  is  the  area  of  mergers  and  acquisitions.  Shaver  described  a  negative  side 
effect  of  mergers,  which  can  also  apply  to  interconnected  IT  systems: 

First,  integration  of  the  two  businesses,  in  a  way  to  effectively 
capture  synergies,  makes  them  more  interdependent.  Therefore, 
negative  shocks  to  one  of  the  businesses,  stemming  from  changes 
in  the  environment  or  actions  by  competitors,  are  more  likely  to 
have  an  impact  across  businesses  of  the  integrated  firm,  compared 
to  if  it  had  not  been  integrated.  (2006,  p.  962) 

The  application  to  IT  portfolios  in  this  case  echoes  that  of  the  financial  systems 
example,  due  to  the  complexity  and  interconnected  nature  of  enterprise  systems. 
“Interconnected”  in  this  sense  does  not  necessarily  refer  to  technical 
specifications  such  as  intra-system  data  exchange  (though  this  can  be  true)  but 
also  includes  interdependencies  during  the  entire  project  lifecycle,  such  as 
requirements  generation,  design,  and  testing. 

The  contagion  effect  can  also  permeate  the  teams  working  on  the 
programs  and  subordinate  projects  mentioned  above.  As  a  subordinate  project  is 
impacted  by  external  shocks,  an  emotional  toll  is  taken  on  the  teams.  Barsade 
studied  “Group  emotional  contagion,  the  transfer  of  moods  among  people  in  a 
group,  and  its  influence  on  work  group  dynamics”  and  showed  “...that  emotional 
contagion  does  occur  in  groups  and  inasmuch  as  emotional  contagion  changes 
people's  moods  and  serves  as  affective  information,  people  are  ‘walking  mood 
inductors,’  continuously  influencing  the  moods  and  then  the  judgments  and 
behaviors  of  others”  (2002,  p.  667). 

Finally,  the  propagation  of  negative  moods  among  teams  influences  the 
individual’s  desire  to  perform.  Rutner  “examines  an  IT  professional's  emotional 
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dissonance... as  a  factor  of  IT  professionals’  work  exhaustion,  job  satisfaction, 
and  turnover  intention”  (2008,  p.  635).  Work  exhaustion,  in  turn,  leads  to 
increased  turnover  (Moore,  2000). 

Contagion  effects  move  throughout  the  portfolio,  organization,  team,  and 
individual  levels  with  varying  degrees  of  severity. 

F.  SUMMARY 

In  this  chapter,  the  rationale  for  enterprise  IT  was  explored.  Development 
and  management  of  enterprise  IT  systems  and  associated  complexity  was 
discussed.  The  importance  of  the  portfolio,  rather  than  simple  project  level  view 
was  emphasized.  The  concept  of  organizational  realities,  and  the  influence  of 
explicit  and  implicit  factors,  was  introduced.  The  contagion  effect  was  defined 
and  proposed  to  potentially  result  from  interaction  of  organizational  factors.  The 
case  study  analysis  of  Chapter  IV  utilizes  this  structure  to  frame  the  results. 
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III.  WATCHKEEPER  AND  MASI:  INTERCONNECTED 
ENTERPRISE  SYSTEMS 


A.  OVERVIEW 

The  WatchKeeper  (WK)  information  system  was  a  major  acquisition 
managed  by  the  USCG  Acquisition  Directorate  (AD,  CG-9),  with  development 
governed  by  the  Major  Systems  Acquisition  Manual  (MSAM)  and  Systems 
Engineering  Life  Cycle  (SELC).  The  Mission  and  Asset  Scheduling  Interface 
(MASI)  information  system  was  a  non-major  acquisition  managed  by  the 
Command,  Control,  Communications,  Computers  and  IT  (C4&IT)  Directorate 
(CG-6)  in  accordance  with  the  USCG  System  Development  Life  Cycle  (SDLC).  In 
order  to  better  understand  what  this  means,  an  explanation  of  pertinent  USCG 
organization  and  a  primer  on  SDLC,  MSAM,  and  SELC  follows.  Full  SDLC  and 
MSAM  documentation  is  available  from  both  the  CG  and  DHS.  The  emphasis 
here  is  on  the  roles  and  responsibilities  of  the  organizations,  and  the 
methodologies,  specifically  where  they  overlap,  rather  than  on  the  process  and 
steps  themselves. 

B.  USCG  PERTINENT  ORGANIZATION 

CG  organizational  structure  as  it  pertains  to  the  WK  and  MASI  case  study 
is  presented  here,  along  with  primary  roles  and  responsibilities.  Figure  6 
illustrates  CG  headquarters  directorates.  Pertinent  to  the  case  study  are  CG-6, 
CG-7,  and  CG-9. 
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Commandant 


Vice  Commandant 


Figure  6.  USCG  Headquarters  Directorates  (after  USCG,  2014) 

1.  CG-6:  Command,  Control,  Communications,  Computers  &  IT 

Directorate 

Figure  7  illustrates  the  pertinent  CG-6  organizational  structure,  and  explicit 
lines  of  authority.  Additional  detail  and  divisions  have  been  removed  to  avoid 
confusion. 
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Figure  7.  C4IT  Service  Center  (SC)  Organization  (after  USCG  SC, 

2014) 


•  C4&IT  Mission:  “The  Assistant  Commandant  for  Command, 
Control,  Communications,  Computers  and  Information  Technology 
(C4&IT)/CG-6  designs,  develops,  deploys,  and  maintains  C4&IT 
solutions  for  the  entire  Coast  Guard  to  enable  mission  execution 
and  achieve  the  Coast  Guard’s  goals  of  maritime  safety,  security, 
and  stewardship”  (USCG,  2014). 
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•  C4&IT  Vision:  “A  Coast  Guard  ready  with  the  right  information  at 
the  right  time  to  safeguard  the  Nation’s  maritime  domain”  (USCG, 
2014). 

•  C4IT  SC  Mission:  “To  be  an  adaptive  and  affordable  service 
provider  and  protector  of  information  and  infrastructure  that  enable 
the  Coast  Guard  to  effectively  execute  its  missions”  (USCG  SC, 
2014). 

•  C4IT  SC  Vision:  “Enable  Coast  Guard  mission  execution  by 
providing  high  quality”  (USCG  SC,  2014): 

•  Information  and  situation-awareness  products  and  services, 

•  Depot-level  maintenance  and  repair  services, 

•  Resource  transparency  and  total  asset  visibility,  and 

•  Stewardship  and  configuration  management.  (USCG  SC, 
2014) 

•  C4IT  SC  Purpose:  “To  enhance  Command,  Control, 
Communications,  Computers  and  Information  Technology's  (C4IT) 
value  in  the  performance  of  CG  missions  by  providing  and 
supporting  systems  and  solutions  that  meet  mission  requirements” 
(USCG  SC,  2014). 

The  C4IT  SC  was  established  February  9,  2009  with  the  intention  of 
combining  all  CG  C4IT  under  a  single  management  structure: 

C4IT  Service  Center  consolidates  electronics  and  IT  support, 
including  that  provided  by  C3CEN  [Command,  Control,  and 
Communications  Engineering  Center],  TISCOM 
[Telecommunications  and  Information  Systems  Command],  OSC 
[Operations  Systems  Center],  and  the  Base  C4IT  Departments  in 
order  to  provide  depot-level  information-technology  support  for  all 
mission  requirements.  (USCG  SC,  2014) 

Of  note  in  the  responsibilities  of  the  C4IT  SC  is  that  they  “Develop[s],  test, 
deliver,  and  support  all  command  &  control,  communications,  computer  and 
information  technology  systems,  applications,  and  services”  (USCG  SC,  2014). 
Although  the  C4IT  SC  consolidates  the  COEs  on  an  organizational  chart,  and 
provides  another  layer  of  hierarchy,  operation  of  the  individual  COEs  remained 
largely  unchanged. 
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a.  Centers  of  Excellence 

The  CG  has  three  geographically  separate  centers  of  excellence  (COEs) 
in  IT  which  support  the  mission  of  the  C4IT  SC.  The  COEs  are  peer 
organizations  under  the  C4IT  SC.  Duplication  of  effort  is  undesirable  but  due  to 
largely  autonomous  operation  of  COEs  before  formulation  of  the  C4IT  SC, 
duplicative  development  efforts  persist,  particularly  between  OSC  and  C3CEN. 
The  COEs  each  have  a  rich  heritage,  and  firm  commitment  to  success,  but  they 
also  see  themselves  as  individual  clans  from  a  control  perspective,  and  often  find 
themselves  in  competition,  rather  than  cooperation. 

(1)  C3CEN:  C3CEN  is  located  in  Portsmouth,  Virginia.  Among  their 
responsibilities: 

The  Command,  Control,  and  Communications  Engineering  Center 
(C3CEN)  develops,  builds,  fields,  trains,  and  supports  advanced 
electronic  command,  control,  and  navigation  systems.  C3CEN 
facilitates  evolutionary  engineering  that  focuses  on  the  rapid 
deployment  of  essential  functionality  followed  by  planned 
improvements  based  on  enhanced  or  refined  requirements.  (USCG 
C3CEN,  2014) 

•  Mission:  “We  deliver,  manage,  and  support  mission-enabling 
Command,  Control,  Communications,  Surveillance,  and  Navigation 
Capability  through  engineering  rigor  and  standard  processes  you 
can  trust”  (USCG  C3CEN,  2014). 

•  Vision:  “We  will  be  the  CG  &  DHS  premier  engineering,  lifecycle, 
and  service  management  center  for  Command,  Control, 
Communications,  Surveillance,  and  Navigation  systems”  (USCG 
C3CEN,  2014). 

(2)  OSC:  OSC  is  located  in  Kearneysville,  West  Virginia,  and  more 
narrowly  defines  their  focus  on  MAIS.  “The  United  States  Coast  Guard 
Operations  Systems  Center  (OSC)  is  a  government-owned,  contractor-operated 
facility  with  the  primary  function  of  providing  full  life-cycle  support  for 
operationally-focused  Coast  Guard  Automated  Information  Systems”  (USCG 
OSC,  2014). 

•  Mission:  “The  OSC  develops,  fields,  maintains  and  provides  user 
support  for  Coast  Guard  enterprise  information  systems  to  improve 
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Coast  Guard  mission  performance  through  the  innovative 
application  of  technology”  (USCG  OSC,  2014). 

•  Vision:  “To  be  the  Premier  Software  Development  Center  for  the 
Coast  Guard  and  the  Department  of  Homeland  Security”  (USCG 
OSC,  2014). 

(3)  TISCOM:  TISCOM  is  located  in  Alexandria,  Virginia,  and  focuses 
on  infrastructure  as  well  as  associated  information  assurance  concerns.  MAIS 
must  satisfy  TISCOM  infrastructure  requirements  in  order  to  operate  on  the  CG 
network.  “TISCOM  is  a  part  of  the  C4IT  Service  Center  and  serves  as  the  Coast 
Guard's  Center  of  Excellence  (COE)  for  enterprise  information  technology 
infrastructure”  (USCG  TISCOM,  2014). 

2.  CG-7:  Capability  Directorate 

•  Mission:  “Capabilities  Provider — The  directorate  responsible  for 
identifying  and  providing  capabilities,  competencies,  and  capacity 
and  developing  standards  for  the  staffing,  training,  equipping, 
sustaining,  maintaining,  and  employing  CG  forces  to  meet  mission 
requirements”  (USCG,  2014). 

CG-7  is  commanded  by  a  rear  admiral  and  includes  several  sub-units. 
Pertinent  sub-units  to  the  WK  and  MASI  case  study  are: 

•  CG-741 :  Office  of  Shore  Forces 

•  Mission:  “The  mission  of  Coast  Guard  Shore  Forces  is  to 
provide  unity  of  command,  and  align  shore  structures  to 
improve  mission  execution  of  all  Coast  Guard  missions  in 
the  maritime  domain”  (USCG,  2014). 

•  CG-761  Office  of  C4  &  Sensors  Capabilities 

•  Mission:  “CG-761  is  a  team  of  professionals  representing  all 
mission  communities  who  combine  Coast  Guard  operations 
experience  and  various  C4  &  Sensors  knowledge  to  achieve 
mission  execution  capability  and  system  interoperability  with 
outside  agencies.  Using  this  unique  combination,  CG-761 
liaisons  between  stakeholders,  user  communities  and 
technical  authorities  to  generate  requirements,  set  priorities, 
and  negotiate  fulfillment  of  user  C4  &  Sensor  needs”  (USCG, 
2014). 
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3.  CG-9:  Acquisition  Directorate 

•  Mission:  “Efficiently  and  effectively  deliver  the  capabilities  needed 
to  execute  the  full  range  of  Coast  Guard  missions”  (USCG  AD, 
2014). 

The  CG  Acquisition  Directorate  was  established  in  2007,  consolidating 
prior  directorates  and  offices  in  order  “to  provide  a  single  point  of  management 
and  to  act  as  the  systems  integrator  for  all  Coast  Guard  Major  Systems 
Acquisitions”  (USCG  AD,  2013,  p.  1.2).  CG-9  is  commanded  by  a  rear  admiral, 
and  manages  significant  funds.  “The  Coast  Guard  is  investing  approximately  $30 
billion  in  major  acquisition  projects  that  purchase  and  modernize  the  service’s 
ships,  boats,  aircraft,  and  command,  control,  communication,  computers, 
intelligence,  surveillance  and  reconnaissance  (C4ISR)  systems”  (USCG  AD, 
2014).  Acquisition  directorate  projects  include  major  information  systems 
development  such  as  CG-LIMS  (enterprise  logistics),  Rescue  21  (direction  and 
location),  and  IOC  (includes  WK).  Of  particular  interest  to  WK  and  MASI  are: 

•  CG-93:  Director  of  Acquisition  Program  Executive  Officer 

•  “Provides  certified  acquisition  management  of  the  Coast 
Guard’s  investment  programs.  CG-93’s  Level  1  (totaling 
more  than  $1  billion  in  lifecycle  cost)  and  Level  2  (totaling 
between  $300  million  and  $1  billion  in  lifecycle  cost)  projects 
deliver  the  service’s  next-generation  aviation,  surface  and 
C4ISR  assets”  (USCG  AD,  2014). 

•  CG-9333:  Project  Manager  (Command21/IPSOC) 

•  Command21  was  the  prior  name  for  the  WatchKeeper 
project  which  is  the  “heart”  of  the  Interagency  Operation 
Centers  mandated  by  the  SAFE  Port  act  of  2006. 

4.  CG-DCMS:  Deputy  Commandant  for  Mission  Support 

“The  Deputy  Commandant  for  Mission  Support  (DCMS)  organization  is 
responsible  for  all  facets  of  life-cycle  management  for  Coast  Guard  assets,  from 
acquisition  through  decommissioning”  (USCG  DCMS,  2014).  CG  assets  include 
acquisitions  and  IT  systems.  DCMS  holds  technical  control  over  CG-6  and  CG-9 
and  is  commanded  by  a  vice  admiral  (0-9). 
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The  four  DCMS  Assistant  Commandants,  CG-1  (Human 
Resources),  CG-4  (Engineering  and  Logistics),  CG-6  (C4IT)  and 
CG-9  (Acquisitions),  coordinate  the  planning,  policy  and  budget  for 
six  Logistics  and  Service  Centers  in  the  field.  The  centers  provide 
the  technical  authority  and  oversight  for  maintenance  and  support 
of  all  Coast  Guard  assets.  (USCG  DCMS,  2014) 

5.  CG-6  and  CG-9  Interaction  in  IS  Development 

The  activities  of  CG-6  and  CG-9  have  the  potential  to  overlap,  particularly 
in  the  case  of  IT  systems  acquisition  and  development,  and  they  are  directed  to 
cooperate: 

Working  closely  with  Coast  Guard  Headquarters  partners,  such  as 
the  Assistant  Commandant  for  Engineering  and  Logistics  (CG-4) 
and  the  Assistant  Commandant  for  C4IT  (CG-6),  the  Acquisition 
Directorate  develops  acquisition  strategies  that  deliver  affordable 
assets  that  meet  mission  requirements,  as  defined  by  the  Deputy 
Commandant  for  Operations,  and  sponsored  by  the  Assistant 
Commandant  for  Capability  (CG-7).  (USCG  AD,  2014) 

Although  strategy  is  formed  jointly,  a  major  acquisition  project  is  developed  and 
controlled  by  CG-9.  In  enterprise  systems,  however,  one  system  may  rely 
extensively  upon  another  system.  A  CG-6  system  may  become  an  integral  part  of 
a  larger  CG-9  system.  In  this  case,  who  ultimately  makes  decisions  for  the  CG-6 
system?  Figure  8  illustrates  the  process  by  which  other  CG  directorates  may 
have  input  in  acquisition  programs.  System  reviews  with  participation  of  CG-6  are 
typically  at  the  senior  executive  level.  The  executive  oversight  council  (EOC)  is 
described  as: 

A  Flag/SES-level  forum  that  monitors  major  risks,  addresses 
emergent  issues,  reviews  [acquisition  decision  event]  ADE  exit 
criteria,  and  provides  direction  to  cross-directorate  teams  as 
required  to  support  successful  execution  of  major  acquisition 
projects.  The  EOC  includes  key  stakeholders  in  the  acquisition 
process.  (USCG  AD,  2013,  p.  7.2) 

Although  the  EOC  includes  stakeholders,  they  are  also  at  the  senior  level.  A 
potential  issue  in  portfolio  development  involving  CG-6  and  CG-9  systems  is  lack 
of  direction  to  the  cross  directorate  teams  due  to  the  abstracted  view  seen  by 
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senior  management.  The  EOC,  by  its  nature,  is  more  focused  on  major  risks  and 
emergent  issues  than  resolution  of  system  requirements  or  interoperability 
concerns  at  the  touch-points  between  CG-6  and  CG-9  systems  at  the 
development  level.  Raising  low  level  concerns  to  the  attention  of  the  EOC  is  not 
typically  practical  or  preferable.  If  the  sponsoring  directorate  between  the 
different  systems  is  the  same,  requirements  can  be  clarified  between  systems; 
however  coordination  of  development  schedules  remains  problematic. 
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Figure  8.  Coast  Guard  Acquisition  Review  Organization  (from  USCG  AD,  2013,  p.  1 .6) 
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For  additional  detail  in  Acquisition  Directorate  organization  as  well  as 
decision  making  bodies,  see  the  USCG  Major  Systems  Acquisition  Manual 
(MSAM)  referenced  (USCG  AD,  2013)  below. 

C.  USCG  SDLC  AND  MSAM/SELC 

1 .  Overview 

The  CG  acquisition  process  follows  the  DHS  Acquisition  Directive  102-01 
series  which  consolidates  DHS-wide  acquisition  management  policy.  MSAM 
governs  major  C4IT  acquisitions,  while  SDLC  governs  non-major  C4IT  programs. 
“All  USCG  C4&IT  acquisitions  not  following  MSAM,  shall  follow  the  SDLC” 
(USCG  C4IT,  201 1 ,  p.  1 ).  When  the  need  for  a  C4IT  system  is  determined,  CG-6 
facilitates  the  decision  process  of  major  versus  non-major  primarily  based  on  Life 
Cycle  Cost  Estimates  (LCCEs).  All  potential  systems  are  initiated  within  the 
SDLC  process.  When  an  acquisition  is  determined  to  be  “major,”  MSAM 
processes  will  be  followed.  SELC  is  part  of  the  MSAM  process.  “MSAM  includes 
satisfying  the  requirements  of  the  SELC.  Commandant  (CG-6)  is  responsible  for 
conducting  SELC  Reviews”  (USCG  C4IT,  2011,  p.  29).  Figure  9  illustrates  the 
high  level  process. 
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Figure  9.  Major  (MSAM/SELC)  and  Non-Major  (SDLC)  Acquisition  Flow  (from  USCG  C4IT,  201 1 ,  p.  30) 
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2.  SDLC  Purpose,  Scope,  Roles,  and  Responsibility 

•  Purpose:  “The  Coast  Guard  SDLC  process  is  a  comprehensive 
management  approach  that  conceives  and  implements  technology 
solutions  designed  to  ensure  that  the  right  organizations  and 
individuals  are  involved  in  each  phase  of  the  process,  thereby 
raising  the  probability  of  success”  (USCG  C4IT,  201 1 ,  p.  1 ). 

•  Scope:  SDLC  applies  to  all  non-major  C4&IT  systems. 

Figure  10  illustrates  the  SDLC  roles  and  responsibilities  framework.  The 
framework  establishes  directorate  roles  and  illustrates  the  coordination 
necessary  for  C4IT  system  and  services  development.  The  three  groups  shown 
impact  stakeholders,  users,  and  customers  (USCG  C4IT,  2011). 
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Figure  1 0.  SDLC  System  Centric  Roles  (from  USCG  C4IT,  201 1 ,  p.  3) 
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•  Asset  Manager  (AM):  “Shall  guide,  oversee,  and  monitor  execution 
of  SDLC  for  the  assigned  system.  The  Asset  Manager  shall 
collaborate  with  the  Sponsor’s  Representative,  the  SDA,  and  the 
System  Support  Agent  (SSA)  to  ensure  alignment  and  compliance 
with  SDLC  policies  and  practices”  (USCG  C4IT,  201 1 ,  p.  4). 

•  Sponsor:  “The  sponsor  has  typically  identified  the  ‘need’  and 
hence  defines  and  validates  program  goals  and  functional 
requirements,  and  officially  accepts  the  final  system.  Interaction 
with  the  sponsor  via  the  sponsor’s  representative  is  critical  to 
defining  the  right  system.  Among  the  sponsor’s  responsibilities  is 
acquiring  the  resources  to  implement  and  support  the  system 
through  collaboration  with  the  sponsor’s  representative  and  the 
asset  manager.  In  keeping  with  the  responsibility  to  define 
requirements,  the  sponsor  identifies  and  facilitates  resolution  of 
issues  related  to  requirements”  (USCG  C4IT,  2011). 

•  Sponsor’s  Representative:  “Designated  by  the  sponsor  to  directly 
liaise  with  AM,  SDA,  and  SSA.  This  team  works  closely  with  each 
other,  customers,  users,  and  stakeholders.  The  sponsor’s 
representative  is  responsible  for  articulating  requirements  on  behalf 
of  the  sponsor,  as  well  as  developing  cost  estimates  and  resolving 
development  issues  with  the  team  at  this  level.  Also  relays  change 
requests  and  collaborates  in  creation  of  the  SDLC  tailoring  plan” 
(USCG  C4IT,  2011). 

•  System  Development  Agent  (SDA):  “The  identified  individual, 
unit,  firm,  agency,  or  organization  that  performs,  or  has  the 
responsibility  for,  design,  development,  and  implementation  of 
C4&IT  systems,  as  well  as  the  acquisition  of  C4&IT  products  or 
services”  (USCG  C4IT,  2011,  p.  7).  Collaborates  with  AM, 
sponsor’s  representative,  and  SSA,  as  well  as  customers,  users, 
and  stakeholders. 

•  System  Support  Agent  (SSA):  “The  SSA  is  the  identified 
individual,  unit,  firm,  agency,  or  organization  that  has  responsibility 
for  maintenance,  support,  and  availability  of  a  system”  (USCG 
C4IT,  2011,  p.  7).  Among  SSA  responsibilities  are  maintaining  and 
supporting  system  services,  sustaining  availability,  and  defining, 
tracking,  and  reporting  support  measures  (USCG  C4IT,  2011). 

3.  MSAM/SELC  Purpose,  Scope,  Roles,  and  Responsibility 

•  Purpose:  “Acquire  and  deliver  more  capable,  interoperable  assets 
and  systems,  and  high  quality,  timely  services  that  support  Coast 
Guard  forces  in  executing  missions  effectively  and  efficiently” 
(USCG  AD,  2013). 
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•  Scope:  Applies  to  all  major  C4&IT  systems. 

•  Program  Manager  (PgM):  “The  individual  who  has  responsibility 
and  authority  to  determine  the  strategic  vision  of  a  program  [in  this 
context,  a  specific  portfolio  of  functionally  similar  systems].  The 
PgM  is  responsible  for  establishing  a  portfolio  focus  across  projects 
within  the  portfolio.  The  PgM  is  accountable  for  establishing  starts 
and  closeouts,  and  communication  with  entities  outside 
Commandant  (CG-9)”  (USCG  AD,  2013,  p.  1.10).  Unlike  SDLC, 
which  is  system  oriented,  MSAM  adds  a  portfolio  management 
approach  in  addition  to  the  system  oriented  SELC  process.  Details 
regarding  this  critical  function  are  available  in  the  MSAM. 

•  Project  Manager  (PM):  “The  PM  is  the  chartered  individual  who 
has  responsibility  and  authority  to  accomplish  project  objectives  for 
developing,  producing,  and  deploying  a  new  asset  with  logistics 
support  to  meet  identified  operational  requirements.  The  PM  is 
accountable  for  meeting  established  cost,  schedule,  and 
performance  parameters  established  by  the  Acquisition  Decision 
Authority  (ADA),  and  works  under  the  guidance  and  supervision  of 
the... portfolio  Program  Manager”  (USCG  AD,  2013  p.  1.7).  PMs  are 
required  to  integrate  the  three  primary  management  areas  shown  in 
Figure  1 1  into  a  coherent  strategy  to  achieve  specific  cost, 
schedule,  and  performance  parameters  for  their  assigned  projects 
(USCG  AD,  2013,  p.  2.1).  “The  PM  is  the  key  individual  for 
acquisition  project  execution.  PMs  are  accountable  for  the 
successful  execution  of  their  projects.  PMs’  span  of  control  is  such 
that  they  must  be  autonomous,  trained,  resourced,  empowered, 
and  accountable  to  senior  management  for  the  effort.  This  all- 
encompassing  level  of  authority  and  responsibility  is  the  foundation 
for  the  Coast  Guard’s  PM-centric  acquisition  execution  model” 
(USCG  AD,  201 3,  p.  1 .8).  The  PM  level  is  similar  to  that  of  the  AM 
in  the  SDLC  process. 
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•  Sponsor:  Similar  responsibilities  to  those  outlined  in  the  SDLC 
process.  For  SELC  reviews  the  sponsor  is  also  known  as  the  Lead 
Operational  Authority  (USCG  AD,  2013). 

•  Sponsor’s  Representative:  Similar  responsibilities  to  those 
outlined  in  the  SDLC  process. 

4.  SDLC  and  MSAM/SELC  Authority 

The  author  is  not  an  expert  in  either  SDLC  or  MSAM/SELC  processes,  but 
the  documents  are  ambiguous  regarding  whether  CG-6  or  CG-9  wields  final 
control  in  C4IT  system  development  cases.  As  seen  in  the  sections  pertaining  to 
CG  directorates,  mention  is  made  of  collaboration.  MSAM  includes  a  description 
of  Technical  Authorities  (TAs): 

The  Commandant  has  designated  TAs  to  serve  as  the  Coast 
Guard’s  authoritative  experts  in  providing  the  authority, 
responsibility,  and  accountability  to  establish,  monitor,  and  approve 
technical  standards,  tools,  and  processes,  and  certify  projects  in 
conformance  with  statute,  policy,  requirements,  architectures,  and 
standards.  (USCG  AD,  2013,  p.  1.15) 
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The  TA  for  C4IT  systems  is  CG-6:  “Commandant  (CG-6)  is  designated  as  the  TA 
for  the  design,  development,  deployment,  security,  protection,  and  maintenance 
of  all  Coast  Guard  C4IT  systems  and  assets.  C4IT  Systems  Development  Life 
Cycle  (SDLC),  COMDTINST  5230.66  (series),  applies”  (USCG  AD,  2013, 
p.1.16).  Yet  in  the  SDLC  manual  under  a  section  addressing  major  C4IT 
acquisitions:  “Activities  involved  in  the  acquisition  life  cycle  for  major  C4&IT 
acquisitions  are  governed  by  policies  and  practices  outside  of  Commandant  (CG- 
6),  with  Commandant  (CG-6)  satisfying  an  advisory  and  review  role  in  the 
process”  (USCG  C4IT,  2011,  p.  28).  CG-6  formally  reviews  major  acquisition 
progress  during  acquisition  decision  events  (ADEs)  using  criteria  defined  in 
“SDLC  Phase  Exit  Approval,”  though  MSAM  does  not  follow  SDLC.  As  such,  CG- 
6  can  require  additional  information  from  CG-9  during  an  ADE.  Figure  9  also 
illustrates  upon  MSAM  completion  a  C4IT  system  reenters  the  SDLC  process 
flow  for  Operations  and  Maintenance  (O&M).  This  suggests  CG-6  is  able  to 
substantially  influence  the  content  and  process  of  a  major  acquisition  via  the 
power  of  unfavorable  reviews  or  refusal  to  accept  an  acquisition  system  to  O&M, 
and  also  suggests  CG-6  limitation  of  CG-9  PM  authority.  The  process  is  further 
complicated  when  a  portfolio  view  is  embraced,  or  programs  are  considered 
rather  than  individual  projects.  A  major  acquisition  program  may  include  multiple 
projects,  including  non-major  CG-6  projects.  The  problem  introduced  is  lack  of 
control  clarity  for  individual  projects  under  the  larger  program.  Ideally 
collaboration  between  CG-9  and  CG-6  would  suffice,  but  explicit  and  implicit 
organizational  factors  may  cause  conflict. 

5.  SDLC  and  MSAM/SELC  Phase  Comparison 

Although  the  emphasis  of  the  case  study  is  roles  and  responsibilities  for 
SDLC  and  MSAM/SELC,  a  comparison  of  the  SDLC  and  SELC  phases  is 
presented  for  completeness.  Figure  12  illustrates  alignment  between  phases  for 
the  two  methodologies. 
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SPR:  Study  Plan  Review 
SER:  Solution  Engineering 
Review 

PPR:  Project  Planning 
Review 

SDR:  System  Definition 
Review 

PDR:  Preliminary  Design 
Review 

CDR:  Critical  Design  Review 


TRR:  Test  Readiness  Review 
PRR:  Production  Readiness 
Review 

ORR:  Operational 
Readiness  Review 
PIR:  Post  Implemenation 
Review 

PAA:  Phase  Approval 
Authority 


Figure  1 2.  SELC  and  SDLC  Phase  Comparison  (after  USCG  CG6,  201 1 ,  p.1 7) 
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D.  WATCHKEEPER 


1.  Purpose,  Capability,  and  Objectives 

WatchKeeper  (WK)  was  the  enterprise  IT  system  to  be  designed  in 
support  of  the  Interagency  Operations  Centers  (IOC)  project  mandated  by 
section  108  of  the  Security  and  Accountability  for  Every  Port  (SAFEPort)  Act  of 
2006.  Figure  13  is  an  early-concept  graphic  which  illustrates  WK  as  the 
aggregator  of  data  from  several  other  enterprise  systems.  The  overarching  IOC 
project  involved  WatchKeeper  in  addition  to  physical  facilities  and  sensor 
networks. 


Interagency  Operations  Centers 

Figure  13.  WatchKeeper/C21  Early  System  Vision  (from  USCG  AD, 

2010) 
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•  IOC  Acquisition  Project  Purpose:  “To  transform  Coast  Guard 
Sector  Command  Centers  (SCC)  or  other  DHS  infrastructure  to 
host  interagency  members  and  meet  the  challenges  of  interagency 
coordination  and  maritime  security.  The  volume  of  maritime  domain 
awareness  (MDA)  information  necessary  to  manage  Coast  Guard 
and  interagency  operations  has  increased  dramatically  and 
exceeded  the  field’s  capacity  to  collect  and  process  it.  As  the 
Department  of  Homeland  Security  (DHS)  lead  for  maritime  security, 
the  Coast  Guard  needs  new  information  management  capabilities 
to  solve  the  coordination  and  operational  challenges  faced  by 
today’s  interagency  decision  makers”  (USCG  CG761/CG741, 2010, 
p.  ES.1).  A  primary  purpose  was  to  build  lOCs  in  high  priority  ports. 

Initial  plans  for  the  IOC  project  called  for  segment  1  to  be  the  development 
and  fielding  of  the  WK  system,  while  segment  2  would  see  further  refinement  of 
WK  and  integration  with  existing  port  and  waterways  sensor  networks.  Segments 
3  and  4  exceed  the  scope  of  this  study,  and  sensor  integration  was  de-scoped 
and  never  implemented  due  to  funding  and  development  issues. 

The  WatchKeeper  information  system  was  envisioned  to  support  three 
operational  capabilities: 

•  Integrated  Vessel  Targeting  (IVT):  “Integrates  targeting  results  of 
agency-specific  screening  processes  and  builds  a  consolidated 
threat  picture  of  people,  vessels  and  cargo  operating  within  IOC 
OPAREA  as  provided  by  intelligence  and  law  enforcement 
communities  in  support  of  the  Ports,  Waterways  and  Coastal 
Security  mission”  (USCG  CG761/CG741 , 2010,  p.  ES.1). 

•  Interagency  Operational  Planning  (IOP):  “Integrates  federal, 
state,  and  local  asset  status  and  schedules.  Mission  Requests  are 
created  from  Integrated  Vessel  Targeting  results,  along  with  other 
mission  demand  sources,  such  as  regattas,  patrols,  and  escort 
missions.  These  Mission  Requests  are  prioritized  by  IOC  decision 
makers,  who  assign  assets  to  missions.  These  assignments  form 
the  IOC  Daily  schedule”  (USCG  CG761/CG741,  2010,  p.  ES.1). 

•  Operations  Monitoring  (OM):  “Manages  the  IOC  Daily  Schedule 
against  all  emergent  events,  such  as  search  and  rescue,  spills,  and 
other  events  occurring  outside  the  operational  planning  window. 
Creates  and  shares  the  tactical  picture,  including  command  and 
control,  mission  status,  and  status  of  IOC  forces/Blue  Force  Tracks 
(BFT)”  (USCG  CG761/CG741, 2010,  p.  ES.1). 
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Expectations  were  high  for  IOC  and  WK.  The  congressional  mandate  and 
DHS  assignment  of  the  CG  to  handle  the  acquisition  were  a  major  investment  in 
the  ability  of  the  CG  to  deliver  the  expected  system.  Stakeholders  identified  in  the 
SAFE  Port  Act  included: 

U.  S.  Customs  and  Border  Patrol,  U.  S.  Immigrations  and  Customs 
Enforcement,  Transportation  Security  Administration,  the 
Department  of  Justice,  the  Department  of  Defense,  and  other 
Federal  agencies,  State  and  local  law  enforcement  or  port  security 
personnel,  members  of  the  Area  Maritime  Security  Committee,  and 
other  public  and  private  sector  stakeholders  adversely  affected  by  a 
transportation  security  incident  or  transportation  disruption.  (USCG 
CG761/CG741, 2010,  p.  1.1) 

These  stakeholders  were  collectively  referred  to  as  “port  partners”  and  enabling 
port  partner  participation  in  the  WK  system  was  a  key  priority.  As  presented  in 
the  Maritime  Port  Operations  Handbook  (2009)  IOC  objectives  were: 

•  Provide  enhanced  information  sharing  between  port  partners. 

•  Foster  planning  and  coordination  efforts  with  local  DHS  and  other 
Federal,  State,  and  local  partners  on  a  regular  schedule  through 
designated  points  of  contact. 

•  Coordinate  local  asset  operations  to  improve  mission  performance, 
eliminate  redundancy  in  mission  execution  and  avoid  mission 
conflicts. 

•  Conduct  risk  assessment  and  analysis,  resulting  in  risk 
management  of  operations.  (USCG  CG-761  &  CG-741, 2010,  p.  1- 
2) 

2.  Development  Methodology 

The  IOC  project  and  WatchKeeper  were  a  major  acquisition  under  CG-9. 
As  defined  earlier,  CG-6  was  the  technical  authority  for  the  WatchKeeper  C4IT 
system,  and  WK  followed  MSAM/SELC  processes.  In  2012,  WatchKeeper  was 
officially  downgraded  to  a  non-major  acquisition.  For  the  majority  of  its 
development,  however,  it  was  a  major  acquisition,  and  after  the  downgrade  it 
continued  to  be  overseen  by  CG-9333.  The  extent  to  which  the  WK  effort 
conformed  to  MSAM/SELC  is  not  directly  the  emphasis  of  this  study. 
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3. 


Roles 


Chapter  III,  Section  B  defines  relevant  CG  directorates  and  COEs. 
Chapter  III,  Section  C.3  defines  typical  MSAM  roles.  Terminology  in  this  section 
follows  MSAM  except  where  noted.  WK  roles  are  listed  below: 

•  PM:  CG-9333 

•  TA:  CG-6 

•  Sponsor:  CG-741 

•  Sponsor’s  Representative:  CG-761 

•  SDA:  C3CEN.  Although  SDA  is  an  SDLC  term,  it  accurately 
describes  C3CEN  as  the  lead  developers  of  WK. 

•  SSA:  OSC:  SSA  is  also  an  SDLC  term,  but  accurately  describes 
OSC  as  maintaining  WK  physical  servers,  providing  helpdesk 
support,  and  interfacing  with  other  enterprise  systems  on  behalf  of 
WK. 

Both  C3CEN  and  OSC  are  CG  or  government  run,  with  primarily  a 
contractor  workforce.  Several  contracting  companies  were  involved  in 
requirements  gathering  and  development  and  will  only  be  mentioned  as  pertinent 
to  the  case  study. 

E.  MASI 

Figure  14  illustrates  a  sample  view  of  the  MASI  system  as  seen  by  an  end 

user. 
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Figure  14.  MASI  Example  Weekly  View 


1.  Purpose,  Capability,  and  Objectives 

The  predecessor  to  MASI  was  a  system  named  MHS-Ops  (Maritime 
Homeland  Security  Operations).  MHS-Ops  was  originally  selected  by  the 
WatchKeeper  program  as  a  nearly-ready  capability  which  could  fulfill  WK  IOP 
requirements.  IOP  requirements  represented  one  third  of  the  overall  WK  system 
(see  Figure  15).  MHS-Ops  was  a  siloed  system  developed  locally  at  USCG 
Sector  Seattle,  and  used  for  planning  and  scheduling  of  sector  assets  at  Seattle 
and  other  locations.  OSC  was  identified  to  review  the  MHS-Ops  system  for 
suitability  of  inclusion  in  WK,  and  extension  to  full  USCG  use  as  an  enterprise 
tool.  Unfortunately,  security  and  other  operational  flaws  were  revealed  which  not 
only  made  MHS-Ops  unsuitable  for  enterprise  use,  or  use  with  WK,  but  also 
identified  its  continued  use  as  a  risk  to  the  CG.  Fielding  of  an  alternate  system 
was  ordered  by  CG-6,  the  designated  approving  authority  (DAA),  not  only  to 
serve  WK  requirements,  but  also  to  enable  transition  of  MHS-Ops  users  and 
shutdown  of  the  system.  MHS-Ops  users  were  distinct  from  WK  users,  and 
would  not  use  WK. 
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CG  Enterprise  Systems 
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Figure  15.  MASI  Relation  to  WK  Primary  Capabilities  (from  MASI 

development  documents,  201 1 ) 

The  MASI  project  was  conceived  to  deliver  capability  similar  to  MHS-Ops, 
but  in  an  enterprise  system  which  complied  with  established  standards  for 
security  and  quality.  The  system  would  be  used  by  the  USCG  as  well  as  provide 
IOP  functionality  for  WK.  Although  MASI  requirements  would  shift  and  grow 
significantly  throughout  development,  its  primary  purpose  was  to  provide  a  single 
view  of  missions  which  were  planned,  underway,  or  completed,  the  assets 
assigned  to  those  missions,  and  asset  status  and  availability.  The  tool  would 
facilitate  both  horizontal  and  vertical  transparency  by  creating  a  common 
operational  picture,  viewable  by  all  decision  makers.  In  the  case  of  MASI 
functionality  for  WK,  this  included  all  port  partners  external  to  the  CG,  as  well  as 
their  assets,  and  planning  and  scheduling  needs.  Desired  MASI  capabilities  (non- 
WK  specific)  as  outlined  by  LaSalle,  included: 

•  A  single  user  interface  will  provide  a  near-real-time  presentation  of 
all  resources  and  statuses. 
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•  A  single  user  interface  will  provide  a  near-real-time  presentation  of 
all  mission  assignments  planned,  underway,  and  completed. 

•  A  single  user  interface  will  provide  a  near-real-time  presentation  of 
significant  events  that  will  influence  planning  decisions. 

•  Planners  will  enter  planning  and  scheduling  information  and 
decisions  in  one  place:  MASI. 

•  Units  and  command  centers  will  then  use  MASI  to  manage  the 
assigned  missions  and  to  support  post-mission  reporting. 

•  A  single  location  will  be  available  for  the  display  of  resource  and 
mission  planning  and  execution,  optimizing  resource  utilization 
against  the  highest  priority  missions. 

•  Horizontal  and  vertical  awareness  will  be  provided  for  resource  and 
mission  planning,  integration,  and  execution. 

•  The  requirement  for  reporting  will  not  change,  but  the  system  will 
support  standard  reporting  procedures. 

•  MDA  will  be  enhanced  by  providing  command  centers  with  single 
source  visibility  of  all  activities  in  the  area  of  responsibility — 
planned,  underway,  and  completed. 

•  The  system  will  contribute  to  the  standardization  of  data 
management  and,  by  extension,  an  increase  in  data  integrity  within 
authoritative  systems.  (LaSalle,  2013,  p.  38) 

Figure  16  illustrates  high-level  MASI  1.0  architecture.  Figure  17  shows 
MASI  1.2  architectural  alterations  created  to  enable  WK  State  of  the  Port  (SOP) 
functionality.  Figure  18  shows  the  additional  complexity  required  of  the  tool  to 
support  full  WK  IOP  functionality.  Appendix  B  details,  at  a  high  level,  the 
complete  re-architecture  required  between  MASI  1.1  and  MASI  2.0  to  support 
WK  IOP.  The  complexity  required  of  MASI  2.0  was  considerable.  MASI  users 
would  reside  in  multiple  security  domains,  and  exceeded  the  set  of  WK  users. 
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Figure  16.  MASI  1.0  Architectural  Diagram  (from  MASI  development 

documents,  2011) 
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Watchkeeper  SOP 
Data  Feed 


MISLE 


Data  Matrix: 

User  Account  Management: 

MISLE  Users  &  Unit  Authorization 
Unit  Hierarchy: 

AOPS  Unit  Hierarchy 
MISLE  Unit 
Resources: 

ALMIS  -  All  resource  available 
AOPS  -  Resources  not  in  ALMIS 
MISLE  -  Local  Resources 
MISLE  -  AOPS/MISLE  Local  Resource  Statuses 
Schedule  Data: 

MASI  -  DOG  Unit  Status/Missions 
MASI  -  IOC  Resource  Status/Missions 
MASI  -  Mission  to  Resource  Allocation 
Note:  No  mission  related  data  (case/activities)  will 
be  read  from  or  created  in  MISLE 


Figure  17.  MASI  1.2  (SOP)  Architectural  Diagram  (from  MASI  development  documents,  2011) 
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Figure  18.  MASI  2.0  Notional  Architecture  in  Support  of  WK  IOP  (from  MASI  development  documents,  2011) 
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2.  Development  Methodology 

The  MASI  project  was  a  non-major  acquisition  under  CG-6  and  followed 
the  SDLC  process.  Although  MASI  was  expected  to  fulfill  one  third  of  WK 
functionality,  it  was  not  a  subsystem  of  WK.  It  was  an  enterprise  system  in  its 
own  right  that  was  expected  to  couple  with  WK  to  supply  expected  functionality. 
This  placed  the  MASI  system  in  the  interesting  situation  of  being  a  CG-6  project 
susceptible  to  CG-9  direction  via  an  eventual  WK  master  schedule.  The  dynamic 
was  further  complicated  because  CG-6  was  the  TA  for  WK,  creating  an 
ambiguous,  potentially  circular  explicit  authority  structure. 

3.  Roles 

Chapter  III,  Section  B  defines  relevant  CG  directorates  and  COEs. 
Chapter  III,  Section  C.2  defines  typical  SDLC  roles.  Terminology  in  this  section 
follows  SDLC.  MASI  roles  are  listed  below: 

•  AM:  CG-633 

•  Sponsor:  CG-741 

•  Sponsor’s  Representative:  CG-761.  “Initially  Sponsor  and 
Sponsor’s  Representative  roles  were  reversed,  but  for  the  majority 
of  the  project  they  were  assigned  as  stated”  (LaSalle,  2013,  p.  33). 

•  SDA:  OSC 

•  SSA:  OSC 

As  mentioned,  OSC  is  a  CG  facility,  with  a  contractor  workforce.  CG-9  did 
not  hold  an  official  role  in  the  MASI  project  from  an  SDLC  perspective. 

F.  CONCURRENT  DEVELOPMENT  ISSUES  WITH  CG-6  AND  CG-9 
INTERCONNECTED  PEER  SYSTEMS 

The  preceding  sections  of  this  chapter  have  provided  a  great  deal  of 

information  specific  to  CG  operation  and  procedures  for  IT  development  and  IT 

acquisitions.  The  information  was  not  only  provided  to  enable  understanding  of 

the  WK  and  MASI  case  study  analysis,  but  also  to  present  the  very  complex  web 

of  directorate  and  procedural  interdependencies  involved.  Less  complicated 

examples  certainly  exist,  and  successful  development  of  systems  has  been 
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accomplished  by  the  same  entities  which  became  so  entangled  in  the  WK  and 
MASI  development.  An  IT  system  developed  by  a  single  COE,  and  overseen  by 
only  CG-6  or  CG-9  has  at  least  an  industry  average  chance  of  success.  The 
failure  of  the  initial  promise  of  WK  and  the  final  disposition  of  MASI  were  greatly 
influenced  by  the  complex  nature  of  the  programs  themselves,  and  the  intricate 
web  of  intra-directorate  funding  priorities,  clan  control,  and  capacity  issues. 
Chapter  IV  will  demonstrate  the  significant  roles  played  by  the  various 
directorates,  both  at  the  senior  and  middle  management  levels. 

G.  METHODOLOGY  PART  II— VALIDITY  AND  ANALYSIS 

As  mentioned  in  the  “Methodology  Part  1”  section  (Chapter  I,  Section  F), 
validity  is  supported  through  the  use  of  multiple  strategies  (Cresswell,  2009). 
Triangulation,  rich  narrative,  member  checking,  extensive  participant  involvement 
and  explanation  of  participant  bias  were  utilized. 

Using  terminology  from  Chapter  III,  and  assigned  roles  in  Sections  D.3 
and  E.3,  the  participant  observer’s  position  within  WK  and  MASI  may  be  defined. 
The  participant  observer  led  the  MASI  SDA/SSA  team,  and  led  the  WK  SSA 
team.  In  the  MASI  SDA/SSA  leadership  capacity,  the  participant  was  directly 
involved  in  all  MASI  development  team  activity,  all  MASI  requirements  task  order 
(MRTO)  activity,  was  responsible  for  managing  the  project  budget,  participated  in 
extensive  meetings  with  the  middle  management  (0-4)  layer  of  various 
headquarters  stakeholders  (CG-633,  CG-741,  CG-761,  CG-9333),  met  with 
C3CEN  SDA’s,  managed  MASI  project  plans,  and  was  responsible  for  weekly 
MASI  SDA  summaries  provided  to  OSC  command.  The  participant  was  also 
instrumental  in  all  MASI  system  demonstrations  to  senior  stakeholders,  (0-6,  O- 
7,  Senior  Executive  Service — SES)  and  participated  in  several  senior  stakeholder 
program  briefs.  In  the  WK  SSA  leadership  capacity,  the  participant  interfaced 
between  WK  and  all  other  OSC  enterprise  systems  (Customer  Service 
Department — CSD,  Maritime  Awareness  Global  Network — MAGNET,  Marine 
Information  for  Safety  and  Law  Enforcement — MISLE,  Nationwide  Automatic 
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Identification  System — NAIS,  etc.),  provided  WK  infrastructure  support, 
participated  in  middle  management  and  senior  stakeholder  meetings,  and 
completed  a  weekly  summary  of  WK  SSA  events.  The  participant  did  not 
contribute  to  formulation  of  WK  specific  project  plans  or  in  assignment  of 
development  work.  The  participant  budgeted  support  of  the  WK  physical  system 
and  support,  but  was  not  involved  in  the  WK  development  budget.  The  WK  SDA 
team  was  located  at  C3CEN  in  Virginia,  and  the  MASI  SDA  team  was  located  in 
West  Virginia.  The  participant’s  most  detailed  information  originates  from  the 
MASI  SDA  position.  Although  the  WK  SSA  position  afforded  the  participant  an 
extensive  view  of  WK  development,  the  exposure  was  less  direct  than  that 
afforded  by  the  MASI  position. 

Middle  management  interaction  was  a  pervasive  constant  throughout  the 
project  timeline  and  often  occurred  at  CG  headquarters  (CG-9333,  CG-741,  CG- 
633,  and  CG-761).  Military  middle  management  was  typically  at  the  lieutenant 
commander  (0-4)  level,  and  reported  to  the  directorate  heads  at  the  captain  (O- 
6)  level.  Influence  at  levels  higher  than  captain  was  rare,  and  explicitly  noted 
where  it  occurred.  OSC  and  C3CEN  development  teams  reported  to  HQ  middle 
managers  for  project  concerns  (and  to  local  superiors  for  COE  issues).  Middle 
management  and  senior  leadership  data  has  been  gathered  from  official 
meetings  and  frequent  emails,  but  no  direct  perspective  was  available  due  to 
geographical  separation.  The  primary  goal  of  the  participant  observer  was  to  see 
both  programs  succeed  but  he  had  a  more  direct  investment  in  the  MASI 
program. 

Given  the  inherent  complexity  involved  in  the  WK  and  MASI  story, 
simplification  was  necessary  to  enable  focus  on  critical  areas,  while  maintaining 
an  overall  narrative.  To  this  end,  hundreds  of  files,  emails,  requirements,  and 
design  documents  for  both  WK  and  MASI  were  compiled  and  analyzed.  These 
resources,  in  addition  to  participant  program  summaries,  (spanning  2010  to 
2012)  were  used  to  build  a  temporal  timeline  of  significant  WK  and  MASI  events. 
This  timeline  was  comprised  of  six  event  columns  spanning  218  time  segments 
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for  a  possible  1308  events,  although  the  total  was  less  because  every  event 
column  did  not  contain  an  entry  for  each  time  segment.  This  list  was  further 
reduced  to  40  significant  and  representative  events,  which  are  presented  (Table 
2)  and  briefly  explained  (Appendix  A).  The  events  were  chosen  prior  to 
classification  as  “explicit”  or  “implicit,”  and  predated  formation  of  the  propositions 
which  emerged  from  the  study.  These  events  were  classified  according  to 
primary  organizational  factors  defined  in  Chapter  II.  From  this  list,  an  activity 
matrix  was  created  which  illustrates  dependencies  between  events.  From  the 
activity  matrix,  an  activity-on-node  diagram  was  created  to  graphically  illustrate 
temporal  flow  and  event  dependency.  This  diagram  also  represented  “actors”  in 
“swimlanes”  to  further  clarify  the  primary  “owners”  of  an  event,  or  the  primary 
recipient  of  event  action.  Selected  portions  of  the  timeline  were  selected  for 
narrative  treatment  to  further  illustrate  interdependency  of  organizational  factors, 
the  complex  network  problem,  and  contagion  effect.  From  this  analysis,  four 
themes  (sets  of  proposals)  emerged. 

H.  SUMMARY 

Explanation  of  explicit  CG  organization  as  it  pertained  to  the  case  study 
was  presented  in  this  chapter.  The  SDLC  and  MSAM/SELC  processes  were 
reviewed  not  only  to  explain  the  explicit  CG  method  for  IT  development  and 
acquisition,  but  also  to  illustrate  the  ambiguous  nature  of  the  processes.  WK  and 
MASI  were  introduced  to  provide  background  on  their  intended  purpose  and  to 
define  their  interdependencies  at  the  conceptual  level.  Issues  were  discussed 
which  arise  during  concurrent  development  of  interdependent  systems,  one 
governed  by  SDLC,  the  other  by  MSAM/SELC.  Finally,  methodology  and  validity 
were  discussed,  as  well  as  the  method  of  analysis  utilized  in  Chapter  IV. 
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IV.  WATCHKEEPER  PORTFOLIO  IMPACTS 


A.  WATCHKEEPER  DEVELOPMENT  ISSUES 

The  emphasis  of  analysis  in  this  study  is  not  the  extent  to  which  WK 
satisfied  the  objectives  of  the  IOC  program  but  rather  an  investigation  into  how  its 
problems  affected  the  MASI  program,  and  to  a  lesser  extent,  other  portfolio 
programs.  A  summary  of  published  WK  difficulties  is  presented  below  for 
completeness,  as  well  as  in  support  of  claims  presented  during  analysis.  WK  has 
had  well  documented  developmental  issues  spanning  the  process  from 
requirements  through  implementation.  In  two  separate  studies  published  in  2012 
and  2013  the  GAO  notes  the  following  regarding  the  IOC  WK  program: 

•  The  Coast  Guard  has  not  defined  WatchKeeper  requirements,  cost, 
and  schedule  in  accordance  with  established  guidance.  For 
example,  the  Coast  Guard  designed  and  developed  the  initial 
WatchKeeper  segment  without  first  defining  the  specific  functions 
that  the  system  is  to  perform.  (GAO,  2012,  p.  2) 

•  The  Coast  Guard  did  not  fully  define  requirements  prior  to 
designing,  developing,  testing,  and  deploying  WatchKeeper. 
Recognized  guidance  calls  for  first  defining  business  requirements 
that  describe  how  users  will  interact  with  the  system,  and  user 
needs  in  terms  of  what  the  system  is  to  do  and  how  it  is  to  do  it,  to 
ensure  that  the  developed  system  satisfies  user  needs... Although 
the  Coast  Guard  developed  draft  high-level  business  requirements 
for  WatchKeeper,  it  did  not  define  the  specific  functions  that  the 
system  is  to  perform.  (GAO,  2012,  p.  29) 

•  The  Coast  Guard  has  not  developed  a  reliable  cost  estimate  to 
guide  and  inform  the  WatchKeeper  investment.  For  example,  the 
estimate  does  not  include  all  government  costs,  such  as  related 
program-management  costs.  (GAO,  2012,  p.  2) 

•  WatchKeeper  development  and  deployment  has  not  been  guided 
by  a  reliable  schedule  of  the  work  needed  to  be  performed  and  the 
key  activities  that  need  to  occur.  In  particular,  the  schedule  does 
not  link  all  activities  so  that  the  project  office  can  determine  how  a 
slip  in  a  particular  task  may  affect  other  related  tasks,  or  the  overall 
schedule.  (GAO,  2012,  p.  2) 

•  ...according  to  the  October  2009  IOC  Project  Management  Plan, 
Segment  1  (WK)  was  to  be  deployed  to  all  35  sectors  by  March 
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2011  and  Segment  2  by  December  2015.  According  to  the 
Acquisition  Program  Baseline,  which  was  approved  by  DHS  in 
September  2011,  Segment  1  is  now  to  be  deployed  to  17  of  the  35 
sectors  by  June  2012,  and  to  the  remaining  18  sectors  and 
Segment  2  to  all  35  sectors  by  March  2017.  (GAO,  2012,  p.  2) 

•  Prior  to  the  initial  deployment  of  WatchKeeper,  the  Coast  Guard 
made  only  limited  efforts  to  determine  port  partner  needs  for  the 
system.  (GAO,  2013a,  p.  16) 

When  asked  what  they  viewed  as  causes  of  WK  problems,  “Project 
officials  attributed  these  limitations  to  an  aggressive  IOC  development  schedule, 
limited  resources,  and  competing  priorities”  (GAO,  2012,  p.  2).  Although  the 
officials  interviewed  by  the  GAO  in  2011  did  realize  at  a  high  level  where  the 
project  had  gone  astray,  they  did  not  successfully  alter  the  result  by  the  time  of 
the  2013  follow-on  study  (the  focus  of  the  2013  study  was  not  exclusively  the 
IOC  WK  program). 

In  2013,  LCDR  LaSalle  also  commented  on  WK’s  challenges  from  an 
internal  perspective  as  the  sponsor’s  representative  (CG-761).  Regarding  the 
relation  between  CG-7  and  C3CEN  (formerly  named  C2CEN): 

Besides  the  normal  disagreements  and  uncertainties  that  are 
present  in  any  project,  this  project  had  a  level  of  animosity  between 
stakeholders  because  of  military  ranks  that  were  involved.  There 
were  meetings  where  quarreling  dominated  the  agenda,  and  there 
was  a  lack  of  trust  between  stakeholders  that  at  times  bordered  on 
resentment.  C2CEN  felt  that  nobody  trusted  its  efforts,  while  both 
directorates  in  CG-7  felt  that  C2CEN  was  not  being  honest  with  the 
development  efforts  that  were  underway.  (LaSalle,  2013,  p.  51) 

Regarding  the  downgrade  of  the  intended  WK  production  release  to  “technical 
demonstrator”: 

The  WatchKeeper  project  also  failed  to  meet  testing  events. 
Because  of  this  failure,  the  Coast  Guard  finally  decided — with 
pressure  from  the  DHS — to  reduce  the  scope  of  WatchKeeper. 
Therefore,  in  2010,  the  DHS  gave  the  direction  that  WatchKeeper 
was  to  be  deployed  as  a  technology  demonstrator  rather  than  a  full- 
fledged  system  of  record,  which  removed  the  MSAM  requirements 
from  the  WatchKeeper  effort.  This  decision  came  at  a  price.  The 
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WatchKeeper  project  realized  substantial  funding  cuts,  and  there 

was  operational  backlash  as  well.  (LaSalle,  2013,  p.  52) 

Unfortunately,  as  the  remainder  of  the  study  demonstrates,  WK  was 
unable  to  contain  the  effects  from  its  many  developmental  and  managerial 
issues,  as  they  rippled  through  the  portfolio  to  affect  MASI  as  well. 

B.  SIGNIFICANT  WK  AND  MASI  EVENTS  ANALYSIS 

As  outlined  in  Chapter  III,  Section  G,  Table  2  contains  the  abbreviated  list 
of  significant  events  from  the  WK  and  MASI  program  timelines,  which  were  used 
to  construct  the  event  matrix  diagram  in  Figure  19.  Table  2  contains  the  event 
number,  event  name,  type,  category,  and  severity.  Severity  is  rated  on  a  scale 
from  one  to  ten,  with  ten  as  the  most  severe.  The  severity  rating  is  relative  to  the 
effect  of  the  event  on  the  MASI  program.  For  example,  E6  represented  a  critical 
blow  to  WK,  but  had  less  direct  effect  on  MASI,  and  therefore  the  severity  rating 
is  lower.  If  severity  were  geared  to  WK,  E6  would  have  been  an  8.  Appendix  A 
also  lists  the  events  of  Table  2,  but  includes  a  detailed  description  of  each  event 
to  include  date,  supporting  details,  historical  context,  implications,  and  impact. 
The  severity  ratings  were  assigned  based  on  the  effect  of  the  event  on  the  MASI 
program  as  a  whole.  In  this  manner,  impact  may  differ  from  the  severity  rating. 
As  an  example,  event  E4  was  more  severe  than  E3,  but  the  direct  cost  impact  of 
E4  was  significantly  less. 

Discussions  of  requirements  in  the  CG  reflect  three  levels  of  abstraction. 
Operational  requirements  are  the  highest  description  of  need.  Functional 
requirements  are  more  specific,  but  still  insufficient  for  system  design.  System 
level  requirements  are  at  the  level  required  for  coding  and  system  design. 
Creation  of  system  level  requirements  from  functional  requirements  is  often 
referred  to  as  “decomposing”  the  functional  requirements.  This  language  is  used 
extensively  in  Appendix  A,  and  in  the  descriptions  which  follow.  The  brief  listing 
of  events  follows  in  Table  2. 
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Table  2.  WK  and  MASI  Significant  Events  List 


Event 

Number 

Event 

Event 

Type 

Implicit 

Category 

Severity  1- 
10 

El 

IOC  WK  pORD  Published 

Explicit 

3 

E2 

MHS-Ops  Selected  to  Fulfill  WK  IOP  Functionality 

Implicit 

Funding 

Priority 

2 

E3 

Re-write  (MASI  Creation)  and  Discontinuation  of  MFIS- 
Ops  Mandated.  Port  Partner  Access  Critical 

Implicit 

Control 

5 

E4 

MASI  1.0  not  Accessible  By  WK  Port  Partners 

Implicit 

Control 

8 

E5 

IOC  ORD  Published 

Explicit 

3 

E6 

WK  Insufficient  for  Production  Release,  Approved  for 
Release  as  Technical  Demonstrator  Instead,  without 
MASI 

Implicit 

Control 

4 

E7 

MASI  1.0  Test  Deployment  Failure  at  CG  Sector  Seattle 

Implicit 

Control 

8 

E8 

Executive  Oversight  Council  (EOC)  "Getback"  Meeting 

Implicit 

Control 

4 

E9 

IOC  APG  Published 

Explicit 

2 

E10 

MRTO  Created 

Implicit 

Capacity 

5 

Ell 

EOC  Mandated  October  2011  MASI  2.0  Development 
Completion 

Implicit 

Control 

8 

E12 

CG-633/CG-761/CG-741  MASI  1.1  Prioritization 
Decision 

Implicit 

Control 

5 
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Event 

Number 

Event 

Event 

Type 

Implicit 

Category 

Severity  1- 
10 

E13 

IOC  FRD  Published  By  CG-9333  Subcontractors.  CG- 
9333  Attempts  to  Control  and  Limit  MASI 
Requirements  Generation 

Implicit 

Control 

4 

E14 

Power  and  Control  Struggles  Begin  at  Initial  MRTO 
and  Stakeholder  (CG-9333,  CG-761,  CG-741,  C3CEN, 
and  OSC)  Meeting 

Implicit 

Control 

6 

E15 

AMT  Non-Delivery  by  C3CEN 

Implicit 

Capacity 

6 

E16 

CG-9333  Provided  Nine  Months  of  MASI  Funding  for 
2011  Development 

Explicit 

4 

E17 

MASI  1.1  Deployed,  Users  Flappy.  CG-761/CG-741/CG- 
633  Delay  Official  Release 

Explicit 

8 

E18 

MASI  1.1  SDLC  Documentation  Incomplete 

Implicit 

Capacity 

5 

E19 

WK  Does  not  Add  Link  to  MASI  1.1  Contrary  to  EOC 
Mandate 

Implicit 

Control 

4 

E20 

MRTO  Team  Restricted  by  CG-9333 

Implicit 

Control 

5 

E21 

CG-761/CG-741  Do  not  Approve  MASI  2.0  Functional 
Requirements 

Implicit 

Capacity 

4 

E22 

Conflict  Over  FRD  1.1  Content  Between  CG-7  and  CG- 
9333  Further  Delays  Creation  of  System  Level 
Requirements 

Implicit 

Control 

5 

E23 

C4IT-SC  Brief:  WK/MASI  Concerns 

Implicit 

Control 

3 

E24 

2012  MASI  Funding  in  Doubt 

Implicit 

Funding 

Priority 

7 
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Event 

Number 

Event 

Event 

Type 

Implicit 

Category 

Severity  1- 
10 

E25 

WK  Does  not  Utilize  MASI  1.2  for  WK  State  of  the  Port 
(SOP)  Contrary  to  EOC  Mandate 

Implicit 

Capacity 

4 

E26 

Change  of  CG-9333  PM 

Implicit 

Control 

5 

E27 

MASI  Development  Team  Begins  RAD/JAD 
Methodology 

Implicit 

Control 

4 

E28 

Status  Brief  to  Assistant  Commandant  for  U.S. 
Coast  Guard  Capability  (CG-7  RDML) 

Implicit 

Control 

3 

E29 

MRTO  Staffing  Issues/MRTO  Extension 

Implicit 

Capacity 

3 

E30 

CG-9333  Pushes  for  Fundamental  Changes  in 
WK/MASI  Interconnection  (Object  Level  Linkage) 

Implicit 

Control 

6 

E31 

MASI  2.0  Non-delivery  to  WK  for  Integration 

Implicit 

Control 

7 

E32 

CG-9333  Directs  WK/MASI  Technical  Interface 
Meetings  be  Delayed  Until  December  2012 

Implicit 

Capacity 

5 

E33 

Competition  for  2012  Funds  Between  WK  and  MASI 

Implicit 

Funding 

Priority 

9 

E34 

MASI  Status  Brief  to  RDML  (CG-7)  and  SES  (CG-6) 

Implicit 

Capacity 

5 

E35 

CG-9333,  CG-741,  and  CG-761  Hold  "Simple 
Scheduler"  Meetings  Without  Notifying  OSC 

Implicit 

Control 

6 

E36 

MASI  2.0  Demonstration  to  Senior 
Stakeholders/Funding  Pitch 

Implicit 

Funding 

Priority 

7 
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Event 

Number 

Event 

Event 

Type 

Implicit 

Category 

Severity  1- 
10 

E37 

RDML  CG-7  Memo:  MASI  No  Longer  to  Provide  Any 
Functionality  for  WK 

Explicit 

8 

E38 

CG-761  Provides  $200k  Interim  MASI  Funding 

Implicit 

Funding 

Priority 

3 

E39 

Loss  of  55  Percent  of  MASI  Team  Over  Four  Months, 
Including  Technical  Lead  and  Senior  Developer 

Implicit 

Capacity 

8 

E40 

Course  of  Action  (COA)  EOC  Meeting 

Implicit 

Funding 

Priority 

10 

The  event  matrix  diagram  (Figure  19)  illustrates  event  dependencies.  The 
diagram  is  temporal,  and  time  advances  down  and  to  the  right.  Specific  dates  are 
less  important  than  the  sequence  of  events,  but  the  dates  are  listed  in  Appendix 
A.  The  event  in  any  given  row  has  a  dependency  upon  marked  events  in  the 
columns.  An  example  narrative  description  of  event  flow  and  dependency  as 
shown  in  the  matrix  is  given  in  Chapter  IV,  Section  G.  Due  to  the  number  of 
events,  the  matrix  is  cumbersome  to  interpret.  Figures  20  and  21  map  the  events 
to  an  event-on-node  diagram  which  reveals  several  insights  concerning  the  data. 
These  insights  were  used  in  formation  of  propositions  discussed  following  the 
diagram. 
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Figure  19.  Event  Matrix  Diagram 


Figure  20.  Event  Flow  Diagram  Part  1 


75 


Senior  Leader 
Decisions 


CG-9333 

(Acquisition) 

Requirements 

Team 


OSC  MASI 
Requirements 
Team  (MRTO) 


C3CEN  Dev 
Team 


7; 


OSC  MASI  Dev 


e» 


Team 


> 

OO 


Figure  21 .  Event  Flow  Diagram  Part  2 
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A  cursory  view  of  the  events  list  reveals  15  percent  of  the  issues  were 
explicit,  while  85  percent  were  implicit.  Of  the  implicit  events,  47.5  percent  were 
control  related,  22.5  percent  were  capacity  related,  and  15  percent  related  to 
funding  priorities.  From  the  event  matrix  diagram,  dependency  percentages  were 
calculated  as  shown  in  Table  3.  The  relation  of  event  and  dependency 
percentages  is  shown  in  Figure  22.  Implicit  control  issues  dominate  in  both  event 
and  dependency  percentages,  but  the  dependency  percentage  also  increases 
from  the  event  percentages  at  the  expense  of  the  other  categories.  Although 
control  is  most  frequently  exercised,  implicit  funding  priorities  have  the  highest 
average  severity.  The  event-on-node  diagram,  in  combination  with  event 
descriptions  (Appendix  A),  and  project  narratives,  revealed  the  propositions 
discussed  in  the  next  sections. 

Table  3.  WK  and  MASI  Average  Severity  of  Events 


Explicit 

implicit 

Control 

Capacity 

Funding  Priority 

Number  of  Events 

6 

19 

9 

6 

Percentage  of  Total  Events 

15.00% 

47.50% 

22.50% 

15.00% 

Average  Severity 

5.5 

5.26 

5 

6.33 

Number  of  Dependencies 

35 

169 

59 

26 

Percentage  of  Dependencies 

12.11% 

58.48% 

20.42% 

9.00% 
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Priority 
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Figure  22.  Percentage  Comparison  of  Events  and  Dependencies 


As  the  event  matrix  was  mapped  to  the  event-on-node  diagram, 
commonalities  became  apparent.  Groups  of  primary  actors  emerged  and  are 
represented  in  the  diagram  swimlanes.  The  OSC  MASI  development  team  was 
comprised  of  the  SDA  and  SSA  for  MASI,  as  well  as  the  development  team.  The 
OSC  MASI  requirements  team  (MRTO),  was  initially  created  to  decompose  high 
level  IOC  WK  IOP  requirements  to  the  system  level  for  use  by  MASI  developers. 
The  C3CEN  development  team  contained  the  SDA  for  WatchKeeper,  along  with 
government  and  contractor  developers.  The  CG-9333  acquisition  team  included 
mid-level  acquisition  managers  and  IOC  WK  specific  requirements  personnel. 
The  OSC,  C3CEN,  and  CG-9333  swimlanes  represent  clear  clans  from  the 
control  perspective,  as  well  as  organizations  with  separate  capacity  concerns. 
The  “Senior  Leader  Decisions”  lane  included  joint  senior  leadership  meetings 
where  decisions  were  made  concerning  the  IT  programs.  An  example  of  a  senior 
leadership  group  with  decision-making  authority  is  the  EOC  (defined  in  Chapter 
III,  Section  B.5). 

An  extremely  influential  subgroup,  however,  is  not  explicitly  present  on  the 
diagram,  but  exercised  pervasive  influence  throughout  the  entire  process  and 
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over  every  swimlane.  The  group  is  middle  management  (defined  in  Chapter  III, 
Section  G),  and  they  were  present  in  all  headquarters  directorates,  ostensibly 
acting  on  behalf  of  the  0-6  directors.  Middle  managers  were  deeply  involved 
representing  CG-761,  CG-741,  CG-633,  and  CG-9333.  They  also  represented 
individual  clans  from  a  control  perspective,  were  often  at  odds,  and  formed 
shifting  alliances  in  efforts  to  achieve  their  clan  goals.  Ideally,  the  overarching 
IOC  implementation  goal  would  have  overridden  clan  boundaries  and  directorate 
power  concerns,  but  this  was  not  the  case.  As  LaSalle  pointed  out  specifically 
regarding  WatchKeeper: 

The  information  that  was  passed  to  the  decision-makers  [by  HQ 
middle  managers]  was  often  a  more  positive  perspective  than 
reality.  No  group  was  willing  to  be  responsible  for  the  failure  of  the 
project.  Milestone  deliverables  and  expectations  were  all  managed 
in  a  way  that  would  present  the  organizing  group  in  the  best  light. 

From  a  program  management  perspective,  it  was  very  difficult  to 
gauge  the  true  pulse  of  the  project  given  these  realities.  (2013,  p. 

52) 

When  the  program  experienced  difficulties,  clan  delineations  took  precedence, 
rather  than  the  portfolio  goals.  The  effect  of  middle  management  is  further 
detailed  in  the  following  sections  as  well  as  in  event  descriptions  in  Appendix  A. 

C.  PROPOSITIONS  ON  ORGANIZATIONAL  CAPACITY  AND  PROJECT 
EXECUTION 

1.  Proposition  A:  In  the  absence  of  clear  tracking  mechanisms, 
implicit  capacity  issues  are  very  difficult  to  understand,  resulting  in 
systemic  over-commitment  of  personnel  and  resources  in  complex 
organizations. 

2.  Proposition  B:  Firefighting  is  a  common  indicator  of  capacity 
issues,  which  can  be  incorrectly  perceived  as  a  project-level,  rather 
than  an  organization-level,  problem. 

3.  Proposition  C:  Systematic  mechanisms  for  understanding  and 
mitigating  capacity  problems  at  an  organizational  level  are  critical  to 
avoid  compounding  project  delays  and  portfolio  impact. 

Regarding  IT  portfolio  management  in  complex  organizations,  capacity 

issues  are  typically  hidden  and  easily  misdiagnosed  based  on  presentation  of 
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associated  signs  and  symptoms  (Chapter  II  Section  D.3.a).  As  complexity  in  a 
system  increases,  so  do  the  number  of  possible  causes  for  an  undesirable  event. 
A  project  milestone  could  be  missed  for  many  reasons  within  a  small  team: 
shifting  requirements,  equipment  or  software  licensing  delays,  and  unforeseen 
developmental  issues.  As  program  scope  increases,  several  teams  may  be 
involved,  adding  to  the  list  of  possible  causes:  failure  of  other  departments  to 
meet  their  obligations,  delay  of  important  joint  decisions,  scheduling  conflicts 
between  groups,  etc.  Unfortunately,  as  higher  management  attempts  to 
determine  root  cause,  teams  begin  to  consolidate  along  clan  lines,  obfuscating 
the  effort  in  a  desire  not  to  be  perceived  as  the  cause.  Indeed,  if  a  group  actually 
was  the  cause  of  the  miss,  they  may  legitimately  believe  the  cause  lies 
elsewhere,  due  to  the  difficulty  of  perceiving  capacity  issues. 

In  addition,  reporting  of  events  is  often  diffused  by  levels  of  hierarchy 
within  organizations.  A  contracted  development  team  may  report  to  a  manager, 
who  then  reports  to  the  contract  representative,  who  then  addresses  the 
customer  for  whom  a  milestone  has  been  missed.  The  contract  representative 
may  be  justifiably  reluctant  to  report  information  which  reflects  negatively  on  their 
group.  An  analogous  case  within  an  organization  (rather  than  a  contractor),  is 
middle  management  reporting  to  senior  management.  To  further  complicate 
matters,  it  is  common  to  deny  capacity  related  issues  until  they  have  become 
critical. 

Project  teams  are  typically  highly  motivated  in  the  initial  stages  of  project 
development  and  coding.  They  have  a  positive  attitude  and  enthusiastically 
approach  problem  solving.  At  the  team  level,  missing  minor  goals  from  day  to 
day  or  week  to  week  can  be  mitigated  through  shuffling  the  local  schedule, 
applying  more  local  resources  to  an  issue,  working  longer  hours,  or 
compromising  quality  for  a  quicker  solution.  Efforts  at  this  level  are  typically  not 
reported  to  higher  level  managers,  and  in  the  example  of  a  contract  team,  the 
contract  representative  does  not  report  any  issue  to  the  customer  because  the 
problems  at  this  point  are  contained.  The  middle  manager  does  not  report  to  their 
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superior  for  the  same  reason.  Thus,  the  eventual  failure  to  meet  a  milestone  may 
be  the  culmination  of  several  events,  which  are  only  partially  understood  at 
higher  levels.  Certainly  the  discussion  of  whether  or  not  there  is  a  fundamental 
capacity  problem  in  some  areas  may  never  be  contemplated. 

In  the  WK  and  MASI  case  study,  capacity  issues  were  experienced  by  all 
groups  in  Figures  20  and  21  at  various  points.  CG-761,  CG-741,  and  CG-633 
(HQ)  experienced  significant  organizational  level  capacity  issues  and  firefighting 
at  the  middle  management  level.  The  middle  managers  were  each  involved  in 
work  for  multiple  projects  when  MASI  and  WK  alone  required  a  full  time  effort 
(Proposition  A).  In  this  case,  firefighting  syndrome  effects  spread  from  these 
directorates  and  affected  MASI  development  in  particular.  Events  E10,  El  8,  E21, 
E22,  and  E27  were  all  affected  by  capacity  issues  in  these  directorates.  Creation 
of  the  MRTO  team  (E10)  was  necessary  because  the  above  directorates  were 
unable  to  generate  requirements  in  a  timely  manner  (one  of  CG-741’s  primary 
duties,  facilitated  by  the  CG-761  sponsor’s  representative).  The  requirements 
generated  by  MRTO  and  the  MASI  development  team,  however,  required 
specific  approval  by  CG-761  and  CG-741,  which  was  delayed  by  firefighting  on 
other  programs  and  resulted  in  E21  (a  delay  of  two  months  and  churn  by  the 
MASI  team).  The  effort  of  E27  was  hampered  for  the  same  reason.  MASI  1.1 
SDLC  documentation  (El  8)  was  unavailable  due  to  CG-633  capacity  issues,  and 
was  delayed  by  5  months. 

As  indicated  in  Proposition  B,  senior  leaders  noticed  MASI  development 
was  behind  schedule  and  assumed  the  fault  was  with  the  OSC  MASI  team, 
rather  than  recognizing  HQ  capacity  issues  as  a  fundamental  cause.  The  author 
assumes  similar  negative  effects  were  seen  in  the  other  projects  overseen  by 
these  individuals  (due  to  their  firefighting  involving  WK  and  MASI)  but  does  not 
have  specific  data.  Thus  the  capacity  issues  persisted  throughout  the  program’s 
duration  and  propagated  to  infect  other  programs  in  the  portfolio,  both  directly 
and  indirectly  (Proposition  C). 
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The  OSC  MASI  development  team  did  actively  attempt  to  mitigate 
capacity  issues  in  201 0  and  201 1 ,  but  their  options  were  limited  and  they  did  not 
receive  support  from  senior  leadership  (Proposition  A).  Following  event  Ell,  the 
team  immediately  recognized  they  would  be  unable  to  meet  the  deadlines 
imposed  given  the  limitations  placed  upon  them.  Having  their  projected  schedule 
shortened  by  33  percent  and  denied  additional  resources,  they  worked  to  reduce 
the  scope  of  the  project  (according  to  the  project  management  triangle,  seen  in 
Figure  4).  They  repeatedly  briefed  senior  leadership  and  middle  management 
regarding  the  capacity  issues  they  faced,  and  were  eventually  successful  in 
reducing  program  scope,  but  the  success  was  largely  negated  by  the  unresolved 
HQ  capacity  issues  mentioned  above,  and  exacerbated  by  the  imposition  of 
significant  additional  work  (El  2).  MASI  implementation  was  negatively  impacted 
by  the  decisions  of  senior  leaders  who  largely  refused  to  support  capacity 
mitigation  efforts  (Proposition  C). 

Active  vigilance  is  required  to  detect  capacity  issues.  Immediately  upon 
initial  identification  of  what  is  perceived  as  a  capacity  problem,  an  evaluation 
should  take  place  to  determine  if  the  issue  is  at  a  project  or  organizational  level. 
The  true  cause  should  be  sought,  not  to  be  confused  with  the  visible  signs  and 
symptoms  of  the  immediate  problem.  Definitive  action  must  take  place  to  either 
resolve  the  capacity  issue  (additional  funding/personnel)  or  to  adjust  stakeholder 
expectations  (schedule  versus  quality  and  functionality).  If  this  does  not  happen, 
the  capacity  issue  becomes  worse,  firefighting  can  commence  if  not  already 
present,  and  schedule  slips  will  broaden  and  increase  to  include  affecting  the 
schedules  of  dependent  portfolio  projects  (Section  F,  Proposition  A).  Project  plan 
dates  become  essentially  meaningless  in  this  environment,  which  is  very 
important  if  other  projects  depend  on  your  schedule  (as  was  the  case  with  MASI). 
If  the  problem  is  organizational  firefighting,  the  project  itself  may  be 
fundamentally  sound  (which  was  not  the  case  with  WK),  and  the  schedule 
realistic,  provided  the  firefighting  problem  is  isolated  from  the  project  and  dealt 
with  separately  by  the  organization. 
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D.  PROPOSITIONS  ON  ORGANIZATIONAL  CONTROL  MECHANISMS 

AND  PROJECT  EXECUTION 

1.  Proposition  A:  In  the  absence  of  a  clearly  understood  set  of 
control  mechanisms,  the  potential  implicit  control  factor  impact 
increases  with  organizational  complexity. 

2.  Proposition  B:  Middle  management  perception  of  executive 
portfolio  strategy  is  often  limited,  leaving  them  to  utilize  clan  control 
mechanisms  and  unknowingly  creating  goal  divergence. 

3.  Proposition  C:  Prudent  use  of  implicit  control  by  senior  managers 
can  greatly  increase  the  chance  of  success  and  bridge  clan  divides. 

Unless  senior  managers  understand  and  plan  for  the  impact  of  implicit 
control  factors,  they  may  discover  they  have  lost  effective  control  of  their  own 
program.  With  multiple  levels  of  hierarchy,  and  the  presence  of  several  peer-level 
organizations,  several  clans  (from  a  control  perspective)  will  exist.  With 
insufficiently  defined  explicit  organizational  controls,  the  available  space  for  clan 
control  to  operate  increases.  People  tend  to  act  along  clan  lines,  with  portfolio 
concerns  secondary.  As  Elonen  and  Artto  (2003)  note,  project  managers  are 
often  forced  to  utilize  implicit  control  to  secure  resources  for  their  project  to  the 
potential  detriment  of  the  portfolio.  This  is  where  middle  managers  wield  their 
influence.  They  have  enough  power  to  materially  influence  the  course  of  a 
project,  and  the  wherewithal  to  disguise  this  from  senior  managers.  If  the  senior 
manager  does  not  firmly  exercise  explicit  control,  or  utilize  implicit  control  to 
his/her  advantage,  the  middle  managers  may  stray. 

Although  the  CG  is  a  military  organization,  with  the  accompanying 
hierarchy,  IT  portfolio  development  has  consistently  experienced  control 
problems  both  vertically  and  across  peer  directorates.  One  senior  leader 
commented  that  with  so  many  directorates  possessing  veto  power  over  the 
others,  it  was  amazing  anything  was  ever  completed.  Ostensibly,  CG-6,  CG-7, 
and  CG-9  are  peers,  as  explained  in  Chapter  III.  The  COEs  (OSC,  C3CEN,  and 
TISCOM)  are  peers  with  each  other,  under  the  CG-6  C4IT  SC.  In  addition  to  the 
hierarchy  described  above,  peers  were  implied  by  military  rank.  The  WK  EOC 
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was  comprised  of  0-6’s  from  CG-633,  CG-761,  CG-741,  CG-9333,  OSC  and 
C3CEN,  among  others.  In  this  sense,  OSC  and  C3CEN  were  both  peers  to  CG- 
633  and  subordinate  to  CG-6. 

The  formal  control  structure  above  inherently  allows  peer-to-peer  implicit 
control  issues  when  viewed  in  combination  with  their  interleaved  missions  and 
responsibilities  (Proposition  A).  In  a  complex  program  such  as  WK,  formal  control 
was  further  blurred  (vertically)  because  CG-9  directed  the  development  efforts  of 
C3CEN,  a  CG-6  entity.  WK  program  size  and  complexity  increased  control 
challenges.  Development  was  geographically  and  organizationally  distributed 
among  various  directorates  and  contractors.  Lack  of  overall  clear  control 
mechanisms  allowed  dramatic  influence  from  implicit  control  factors,  as 
evidenced  by  the  domination  of  implicit  control  dependencies  seen  over  other 
factors  in  Figure  22  (Proposition  A). 

Peer  implicit  control  factors  were  based  on  organizational  hierarchical 
levels  and  military  rank.  Directorate  leaders  and  senior  peers  influenced  each 
other  (events  E8,  El  6,  E23,  E24,  E26,  E33  and  E40).  Middle  managers  at  CG- 
633,  CG-761,  CG-741,  and  CG-9333  influenced  each  other  (events  E12-E14, 
E19-E22,  E24,  E30,  E33,  and  E37).  C3CEN  and  OSC  cooperated  at  the  lower 
levels,  while  their  0-6  commanding  officers  interacted  laterally  at  the  senior  level. 
Implicit  control  actions  were  overwhelmingly  motivated  along  clan  affiliations 
(described  in  Chapter  IV,  Section  B)  but  often  involved  program  and  portfolio¬ 
wide  consequences  which  were  not  necessarily  intended  by  the  originating  clan 
(Proposition  B). 

An  example  originating  with  CG-9333  illustrates  both  horizontal  and 
vertical  implicit  control,  with  unintended  portfolio  consequence.  Events  El 3,  El 4, 
and  E22  illustrate  events  where  CG-9333  middle  management  attempted  to 
control  MASI  requirements  generation  (lateral  implicit  control  enabled  in 
accordance  with  Proposition  A).  Their  initial  efforts  resulted  in  limited  control  of 
MASI  activity,  although  they  did  cause  MASI  delays.  With  the  departure  of  the 

CG-9333  PM  (E26),  their  middle  management  influenced  the  incoming, 
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inexperienced  PM  (vertical  control),  which  allowed  them  to  introduce  E30  and 
E35,  even  though  E30  was  contrary  to  the  directions  of  the  prior  PM.  CG-9333 
middle  management  desired  control  of  MASI  fulfillment  of  WK  IOP  functionality. 
When  they  did  not  obtain  it  to  their  satisfaction,  they  attempted  to  remove  MASI 
as  a  requirement  for  WK  IOP,  which  they  were  successful  in  doing  (E37).  As  a 
result,  C3CEN  was  forced  to  create  an  inferior  (and  largely  manual)  IOP  solution, 
which  fulfilled  less  than  one  fourth  of  the  requirements  MASI  would  have 
provided  (Proposition  B). 

Creation  of  this  solution  impacted  completion  of  other  WK  development, 
and  was  a  critical  influence  to  the  cessation  of  MASI  development  (E40).  During 
this  time,  the  CG-761  director,  secure  in  his  explicit  control,  committed  additional 
funds  to  MASI  (E38)  and  ordered  his  middle  managers  to  secure  further  funding. 
Contrary  to  his  wishes,  the  middle  managers  advised  the  EOC  to  cease  MASI 
development.  Had  the  CG-761  director  been  aware  of  the  implicit  control 
struggles  taking  place  around  him,  he  may  have  been  able  to  achieve  his  goal 
rather  than  being  marginalized  (Proposition  C).  Cardinal,  (2001;  Cardinal  et  al., 
2004)  and  Kirsch  (1997,  2004)  argue  clan  control  can  complement  formal  control, 
and  had  he  been  aware,  he  could  have  used  this  to  his  advantage,  both  vertically 
and  with  his  peers.  CG-9333  middle  management  believed  they  were  acting  in 
the  best  interest  of  WK  (Proposition  B),  and  the  result  was  a  less  capable  tool 
and  additional  consumption  of  C3CEN  development  resources. 

Developing  a  complex  program  across  multiple  organizations  in  the 
absence  of  sufficient  control  mechanisms  allowed  extensive  influence  by  implicit 
control  brokers.  These  middle  managers,  however,  did  not  understand  and 
support  the  portfolio  view,  and  were  susceptible  to  clan  mentality.  They 
attempted  to  optimize  locally  for  their  clan  at  the  expense  of  the  higher  program 
and  portfolio.  The  result  was  damage  to  their  program,  as  well  as  to  MASI. 
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E.  PROPOSITIONS  ON  ORGANIZATIONAL  FUNDING  PRIORITIES  AND 

PROJECT  EXECUTION 

1.  Proposition  A:  When  funding  priorities  are  not  clarified  adequately, 
ad  hoc  decisions  regarding  one  project  can  adversely  spread  to 
others  in  the  portfolio. 

2.  Proposition  B:  Periodic  assessment  and  recognition  of  funding 
vulnerabilities  should  take  place  at  the  portfolio  level  to  ensure 
minimized  negative  portfolio-wide  impact. 

3.  Proposition  C:  Following  identification,  realistic  assessment  of 
funding  priorities  at  the  project  level  must  inform  timely  changes  to 
scope,  schedule,  and  quality. 

IT  portfolio  funding  requirements  are  dynamic.  Multi-year  projects 
attributed  annual  funding  amounts  experience  unforeseen  issues  which  may 
require  additional  funding  or  modification  of  project  timelines  and  scope.  When  a 
major  development  program  experiences  significant  upheaval,  an  analysis  of 
portfolio  impact  should  be  performed  in  addition  to  program  review.  Enterprise  IT 
systems  have  direct  and  indirect  effect  on  other  programs  in  the  portfolio. 

The  MASI  program  was  vulnerable  to  funding  priorities  from  inception. 
CG-9333  managers  initially  chose  MHS-Ops  as  an  existing  solution  they  believed 
would  be  usable  at  an  enterprise  level  (E2).  CG-6  identified  MHS-Ops  security 
vulnerabilities  and  mandated  the  program  be  re-written  (E3).  At  this  time,  CG-6 
should  have  identified  funding  in  accordance  with  SDLC  requirements.  They  did 
not  realize,  however,  the  scope  of  the  project  and  proceeded  without  identifying 
sufficient  funding  in  violation  of  the  SDLC.  Funding  pressure  directly  affected 
schedules  and  design  choices  throughout.  In  2011,  in  particular,  funding  priorities 
caused  non-replacement  of  departing  engineers.  This  fundamental  vulnerability 
was  fatal  when  WK  realized  they  had  funding  troubles  of  their  own  for  2012,  and 
competed  with  MASI  to  obtain  them.  Portfolio  funding  issues  affected  both  MASI 
and  WK  as  detailed  below. 

In  July  2010,  the  CG-9333  PM  realized  the  program  possessed  excess 
expiring  funds  which  would  have  been  wasted  if  unused.  He  wanted  to  maximize 
the  value  the  funds  could  provide  both  to  WK  and  other  programs  in  the  portfolio. 
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He  polled  the  other  programs  providing  direct  or  indirect  services  for  WK,  and 
determined  whether  they  were  experiencing  funding  shortages.  The  connection 
to  MASI  was  direct,  in  that  MASI  was  to  provide  WK  IOP  functionality.  The  PM 
funded  the  MRTO  team  (E10)  and  the  MASI  team  for  a  portion  of  2011  (El 6). 
They  also  provided  funding  to  the  Enterprise  Geographic  Information  System 
(EGIS).  In  that  case,  WK  was  one  consumer  of  GIS  data  feeds  which  were  also 
needed  by  several  other  portfolio  systems,  not  directly  linked  to  EGIS.  These 
programs  also  benefited.  Timely  identification  was  critical  to  the  responsible  and 
effective  allocation  of  the  surplus  funds  in  a  manner  where  the  benefit  to  the 
portfolio  was  maximized.  It  should  be  noted  that  the  method  followed  by  the  CG- 
9333  PM  to  identify  programs  to  benefit  from  the  WK  funding  surplus  was 
informal.  He  contacted  the  WK  SSA  located  at  OSC  and  inquired.  In  this  case  of 
surplus  funds,  priority  goal  ambiguity  was  not  an  issue,  but  ideally  more  formal 
routes  would  exist  for  CG-9333  to  provide  direct  funding  to  CG-6  programs. 

Funding  deficits  are  more  common  than  surpluses,  and  much  more 
difficult  and  contentious,  to  mitigate.  When  CG-9333  provided  201 1  funds  for 
MASI  development  (El 6)  they  stated  no  additional  funding  would  be  available  in 
2012.  At  the  time,  identified  annual  MASI  funding  was  less  than  one  third  what 
development  required.  In  April  2011,  the  OSC  MASI  team  began  briefing  senior 
leaders  on  the  fiscal  2012  funding  shortage  (six  months  prior  to  the  start  of  fiscal 
year  2012).  As  noted  in  E24,  CG-6  and  CG-7  focused  on  creation  of  alternative 
plans  rather  than  identifying  funding  sources.  This  approach  was  a  viable  method 
given  lack  of  visibility  on  funding  in  general  due  to  the  federal  continuing 
resolutions  experienced  during  the  year. 

In  October  201 1 ,  non-delivery  of  MASI  2.0  (E31 )  was  not  a  surprise,  given 
schedule  extensions  had  been  requested  of  senior  leadership  in  June  2011. 
Given  unknown  2012  funding,  MASI  development  goals  should  have  been 
altered  in  the  second  half  of  201 1  (Proposition  C).  A  reduction  in  scope  would 
have  allowed  fielding  of  a  reduced  system  in  201 1  in  the  event  2012  funding  was 
not  forthcoming.  Lack  of  meaningful  focus  on  identification  of  funding  led  to  E33, 
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direct  competition  for  funds  between  WK  and  MASI  (Proposition  A).  Certainly  at 
this  point  the  portfolio  view  should  have  been  considered  (Proposition  B).  WK 
required  MASI  to  supply  IOP  functionality,  and  non-funding  of  MASI  would  hurt 
WK.  The  two  systems  competing  for  funds  was  entirely  nonsensical,  yet  each 
side  (CG-9333  versus  CG-7/CG-6)  felt  they  would  be  the  beneficiary,  and 
alternative  funding  was  not  seriously  sought  until  December  2011.  WK  was  a 
congressionally  mandated  system,  and  received  the  2012  funding. 

Non-delivery  of  MASI  2.0,  and  lack  of  identified  funding,  led  the  CG-9333 
PM  to  explore  alternatives  to  MASI  (E35)  which  he  was  then  approved  to 
implement  (E37).  Although  CG-761  provided  interim  funding  in  January  2012,  to 
fund  the  MASI  team  until  the  end  of  February  (E38),  it  was  too  late  (Proposition 
A).  The  lack  of  visibility  and  conflict  with  CG-9333  crippled  the  MASI  team,  and 
55  percent  of  the  OSC  team  departed  (E39).  Continued  MASI  development  was 
no  longer  practical  and  the  team  was  dissolved  (E40).  Although  senior  leaders 
were  aware  of  funding  issues  with  MASI  and  WK,  they  did  not  meaningfully 
intervene  or  identify  alternate  funding  in  a  timely  manner.  Furthermore,  they  did 
nothing  to  reduce  the  scope  of  MASI  in  2011  to  allow  fielding  of  a  reduced 
system  (Proposition  C). 

F.  COMPOUNDING  COMPLEXITY:  FACTOR  INTERACTION  AND 

CONTAGION 

1.  Proposition  A:  As  IT  portfolio  complexity  increases,  so  does  the 
episodic  possibility  of  contagion,  amplified  by  insufficient  funding 
clarity,  unresolved  capacity  problems,  and  unregulated  clan  control 
issues. 

2.  Proposition  B:  Lack  of  explicit  organizational  controls  and  periodic 
executive  attunement  to  implicit  factors,  allows  excessive  latitude  in 
middle  manager’s  project  influence,  which  may  be  clan-oriented 
and  contrary  to  portfolio  goals. 

3.  Proposition  C:  Perception  of  the  periodic  influence  of 
organizational  factors  by  portfolio  executives  is  insufficient:  In  the 
absence  of  timely  mitigation  efforts,  minor  contagions  may 
compound  and  amplify,  resulting  in  project  cancellations  and 
adverse  portfolio  impact. 
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Throughout  the  analysis  in  this  chapter,  the  examples  cited  have  shown 
that  as  complexity  increases  (complex  network  problem),  so  does  the  potential 
for  negative  effects  to  the  program  (schedule,  cost,  and  scope)  as  well  as  to  the 
overall  portfolio.  Analysis  of  each  implicit  factor  in  the  preceding  sections  was 
difficult  to  present  without  referencing  the  contributions  of  the  other  factors 
because  they  tend  to  reinforce  each  other  and  propagate  throughout  the  project, 
program,  and  portfolio.  The  result  of  a  series  of  effects  can  be  difficult  to  predict, 
and  difficult  to  analyze,  even  with  the  benefit  of  hindsight.  Effects  not  only  amplify 
and  propagate,  they  can  damage  the  source  program  as  well  as  the  infected  one 
(reciprocal  effects). 

As  noted  in  Chapter  II,  Section  E,  Allen  and  Gale  (2000)  discuss  the 
theory  of  small  financial  sector  shocks  spreading  to  larger  areas  by  contagion. 
Shaver  (2006)  referenced  increased  vulnerability  to  shocks  due  to  increased 
interdependencies  of  merged  businesses.  The  analogous  situation  occurred  with 
WK  and  MASI.  Each  was  a  complex  system  dependent  on  the  other.  MASI  was 
to  provide  WK  IOP  functionality,  although  it  was  also  a  separate  enterprise 
system  supporting  a  non-WK  user  group.  OSC  and  C3CEN  were  expected  to 
develop  interoperability  and  data  sharing  between  the  two  systems.  CG-9333 
and  MRTO  teams  were  dependent  on  each  other  for  program  requirements.  WK 
was  tied  financially  to  MASI  via  CG-9333  funding  in  2011,  and  competition  for 
funds  in  2012  (Proposition  A).  The  EOC  group  was  comprised  of  several  peer 
directorates,  who  made  communal  decisions.  Lack  of  well  understood 
organizational  controls  and  insufficient  senior  leadership  action  allowed  middle 
managers  with  provincial  views  to  make  critical  decisions  (Proposition  B).  Senior 
leadership  acknowledgement  of  implicit  factors  was  insufficient  to  halt  contagion 
(Proposition  C).  The  complex  interaction  between  groups  and  the  contagion 
involving  implicit  factors  combined  to  eventually  result  in  cessation  of  MASI 
development  (E40),  and  the  waste  of  nearly  seven  million  dollars  (explained  in 
detail  throughout  Appendix  A). 
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One  specific  example  of  contagion  began  with  C3CEN,  but  was  itself 
influenced  by  CG-9333.  C3CEN  was  a  group  with  persistent  and  largely 
unrecognized,  or  uncontrolled  capacity  issues.  See  Appendix  A  for  detailed  event 
descriptions  which  complement  this  narration.  Events  E6,  El  5,  E25,  and  E32 
touch  on  C3CEN’s  capacity  issues.  E6  was  an  early  indicator  to  senior 
leadership  that  C3CEN  was  experiencing  serious  development  issues,  but  the 
focus  was  release  of  WK  as  a  technical  demonstrator  without  recognition  of 
fundamental  capacity  issues  (capacity  Proposition  A).  Continuing  capacity  issues 
resulted  in  El 5,  non-delivery  of  the  WK  AMT  tool  to  MASI,  which  required  it  in 
order  to  develop  the  user  identification  and  authentication  module. 

Event  El  5  also  provides  an  excellent  example  of  firefighting.  The  AMT 
tool  was  delayed  for  10  months,  and  finally  delivered  with  minimal,  insufficient 
functionality  (classic  firefighting  symptoms).  The  ongoing  delays  were  a  result  of 
CG-9333  middle  management  continually  re-assigning  C3CEN  developers  to  put 
out  other  fires  within  the  program.  The  delays  of  E32  were  the  result  of  a  CG- 
9333  prioritization  which  was  necessary  because  C3CEN  had  missed  delivery  on 
a  WK  service  pack.  As  fundamental  capacity  issues  remained  unaddressed, 
C3CEN  entered  firefighting  syndrome  and  remained  there  for  the  duration  of  the 
program. 

CG-9333,  CG-761,  and  CG-741  middle  management  obfuscated  the 
severity  of  the  problem  (Proposition  B),  and  C3CEN  experienced  continued 
incremental  schedule  slips,  down-scoping  of  functionality,  and  the  MASI 
schedule  was  adversely  affected  many  times  due  to  dependencies  on  C3CEN 
which  were  missed  (Proposition  A).  See  Appendix  A  for  further  specific  impact 
descriptions.  In  this  case  of  firefighting,  the  capacity  issue  was  within  the  WK 
program.  The  program  was  so  large  that  firefighting  was  able  to  take  place 
among  the  various  WK  groups,  but  it  also  infected  C3CEN  programs  outside  of 
WK  and  became  an  organizational  problem  (Proposition  A).  Specifically, 
resources  were  taken  from  the  C3CEN  Search  and  Rescue  Optimal  Planning 
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System  (SAROPS)  team  to  work  on  WK  fires.  The  author  does  not  have  data  on 
the  extent  to  which  other  C3CEN  programs  were  affected  by  WK  induced 
firefighting. 

Although  senior  leaders  certainly  understood  C3CEN  was  experiencing 
significant  problems,  they  continually  attempted  to  mitigate  the  specific  signs  and 
symptoms,  rather  than  addressing  fundamental  capacity  issues.  WK  capacity 
issues  became  a  source  of  contagion  to  other  portfolio  programs.  Lack  of  senior 
leadership  action  (Proposition  C),  allowed  the  problem  to  perpetuate  throughout 
the  entire  program  duration,  resulting  in  the  situation  warned  of  by  Bohn  and 
Jaikumar:  “the  pressure  of  a  backlog  of  unsolved  problems  leads  engineers  to 
solve  problems  not  just  inefficiently,  but  badly.  As  a  result,  each  problem 
supposedly  solved  has  a  chance  of  creating  a  new  problem,  and  sometimes 
more  than  one”  (2000,  p.  16). 

Full,  in-depth  narrative  of  the  events  in  Figures  20  and  21  is  not  practical, 
but  section  G  below  illustrates  the  complex  interaction  of  only  the  first  seven 
events.  The  description  for  these  events  is  the  most  simple  available  for  the 
program  overall.  They  pre-date  MRTO,  CG-9333  requirements  problems,  and 
funding  issues,  but  even  absent  these  influences  the  complexity  is  apparent. 

G.  RECIPROCAL  AND  REINFORCING  EFFECTS  NARRATIVE: 

CONTAGION 

The  IOC  WK  project  began  with  an  impression  of  being  behind  schedule 
(organizational  slack  was  eliminated  before  the  project  began).  The  SAFE  port 
act  (2006)  required  IOC  establishment  within  three  years  (by  October  2009)  yet 
the  CG  did  not  receive  funds  until  fiscal  year  2008  (14  months  after  passage  of 
the  SAFE  port  act).  Definitions  of  a  fully  operational  IOC  were  also  in  flux  during 
this  time  (GAO,  2012).  The  magnitude  of  the  IOC  project  was  intimidating  and 
although  the  CG  had  two  years  from  initial  appropriations  to  mandated 
completion,  initial  decisions  were  influenced  by  the  sense  of  time  pressure. 
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The  pORD  (Event  1)  was  insufficient  for  developing  a  system  because  it 
“only  provided  a  very  high-level  conceptual  need,  not  system  specific 
requirements”  (LaSalle,  2013,  p.  31)  yet  this  explicit  document  was  the  only 
requirements  resource  available  in  2008.  WK  Segment  1  began  development 
with  this  document  as  the  only  guide.  Time  pressure  influenced  the  selection  of 
MHS-Ops  (Event  2)  as  the  tool  to  support  the  planning  and  scheduling  portion  of 
WK  (later  to  be  known  as  IOP  functionality).  The  hope  was  the  MHS-Ops  system 
would  require  only  a  small  amount  of  work  to  make  it  suitable  for  integration  into 
WK  (an  attempt  to  conserve  capacity  while  reducing  cost  and  shortening 
implementation  time).  When  security  vulnerabilities  and  other  concerns  revealed 
MHS-Ops  as  unsuitable  at  an  enterprise  level  (indeed,  unsuitable  for  continued 
operation  at  its  current  installations)  the  decision  to  re-write  the  tool  was  made 
and  the  MASI  project  was  born  (Event  3). 

The  pORD,  however,  did  not  contain  sufficient  detail  to  enable  meaningful 
requirements  for  MASI,  so  the  vague  goal  became  to  have  the  new  tool  emulate 
MHS-Ops  but  with  the  added  ability  of  port  partner  integration  functionality 
(though  this  was  only  notionally  defined  as  well).  Concerns  regarding  lack  of  port 
partner  related  requirements  were  identified  by  the  OSC  MASI  team  as  early  as 
January  2009,  but  prompted  no  action  from  senior  leaders.  Emulating  MHS-Ops 
was  also  a  poorly  informed  decision,  because  the  PM  and  sponsor  were  unsure 
the  MHS-Ops  functionality  was  suitable  for  IOC  WK  integration  and  functionality, 
due  to  the  lack  of  detail  in  the  pORD.  The  method  by  which  the  two  tools  would 
interact  and  exchange  data  was  undefined  but  middle  managers  pressed  forward 
(clan  control).  Thus,  the  decision  to  proceed  with  development  based  on  the 
pORD  began  the  infection  of  WK  which  was  transmitted  to  MASI. 

The  MASI  team,  forced  to  make  design  decisions  in  the  absence  of 
meaningful  IOC  WK  integration  requirements,  decided  to  bind  their  tool  to  the 
MISLE  system  rather  than  creating  their  own  database.  This  decision  (partially 
informed  by  the  HQ  implicit  control  consideration  to  limit  what  was  viewed  at  the 
time  as  a  proliferation  of  new  databases)  would  have  far  reaching  consequences 
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as  well.  MASI  1 .0  was  originally  scheduled  to  move  to  production  in  December 
2009.  In  August  2009,  TISCOM  disqualified  the  method  by  which  port  partners 
were  to  gain  access  to  MASI,  in  effect  making  it  useless  to  WK  (Event  4).  An 
alternate  proposal  for  port  partner  access  by  the  MASI  team  was  denied  due  to 
lack  of  WK  requirements  (an  implicit  control  decision  by  CG-635).  Partially  due  to 
the  MASI  failure  and  partially  due  to  other  WK  development  problems,  what  CG- 
9333  desired  to  be  the  first  production  release  of  WK  was  deemed  insufficient 
(no  ATO  to  be  granted).  The  program  was  forced  to  deploy  only  as  a  “technical 
demonstrator”  (7  months  after  the  date  mandated  by  the  SAFE  port  act)  without 
planning  and  scheduling  functionality  (Event  6). 

Having  failed  to  enable  port  partner  functionality,  MASI  1.0  was  tested  at 
Sector  Seattle  in  July  2010  to  determine  if  it  could  replace  MHS-Ops  for  CG  use. 
Although  introduction  of  a  new  tool  to  replace  a  well-liked  tool  is  challenging, 
MASI  1 .0  failed  in  its  test  deployment  largely  due  to  issues  created  by  its  close 
coupling  with  the  MISLE  system  (Event  7).  MASI  1 .0  was  never  officially  released 
on  the  recommendation  of  HQ  middle  management. 

The  decision  to  begin  with  the  pORD  as  the  primary  source  of 
requirements  infected  both  the  initial  WK  and  MASI  development  efforts.  In 
conjunction  with  perceived  time  constraints,  this  resulted  in  the  essential  failure 
of  the  initial  version  of  both  tools.  This  is  an  example  of  a  reciprocal  effect,  where 
insufficient  WK  requirements  contributed  to  MASI  1 .0  failure,  which  then 
contributed  to  the  WK  failure  to  obtain  an  ATO.  The  impact  to  the  MASI  team 
was  severe  as  well.  MASI  1 .0  was  generally  considered  a  technically  sound  tool, 
which  was  well  implemented,  but  built  with  what  turned  out  in  hindsight  to  be 
incorrect  requirements.  Twenty  months  of  full  team  development  were  perceived 
as  largely  wasted  and  morale  on  the  team  suffered  greatly.  Although  the  ORD 
was  finished  in  March  2010,  and  was  much  more  robust  than  the  pORD,  it  was 
also  a  high-level  conceptual  document  (Event  5). 
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Several  other  examples  of  adverse  reciprocal  and  reinforcing  effects  may 
be  sussed  out  from  the  descriptions  in  Appendix  A,  in  conjunction  with  Figures  20 
and  21 . 

H.  SUMMARY 

This  chapter,  in  conjunction  with  Appendix  A,  forms  the  bulk  of  the  WK 
and  MASI  case  study  analysis.  Specific  examples  were  given  to  support  the 
assertion  that  WK  was  a  program  which  experienced  significant  problems 
spanning  the  time  frame  of  the  study.  The  analysis  of  events,  including  the  event 
matrix  diagram  and  event  flow  diagram,  were  explained  and  detailed.  Relevant 
statistics  were  presented,  revealing  significant  effect  from  implicit  factors,  and 
several  themes  emerged.  The  themes  were  organized  into  propositions 
regarding  capacity,  control,  funding  priorities,  and  their  interaction.  Finally,  the 
first  seven  events  were  explained  in  a  narrative  style  to  illustrate  an  example  of 
factor  interaction,  and  reciprocal  effects. 
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V.  CONCLUSION 


Information  Technology  (IT)  projects  have  a  well-documented  potential  for 
complexity,  difficulty,  and  failure.  This  thesis  utilized  a  case  study  to  demonstrate 
success  or  failure  depends  not  only  on  the  individual  project  but  also  on  the 
dynamic  interaction  of  organizational  factors  at  the  portfolio  level.  With  MASI  1.1, 
the  OSC  development  team  achieved  success  by  creating  a  tool  that  not  only 
served  the  mission  needs  of  its  user  base,  but  was  also  well-liked  and  easy  to 
use.  The  team  won  the  OSC  “Team  of  the  Quarter”  award  for  its  efforts  (detailed 
in  Appendix  C).  Yet  this  same  team  failed  to  deliver  MASI  2.0  on  schedule  and 
saw  all  development  discontinued.  The  difference  in  the  efforts  was  the 
increasing  entanglement  and  dependency  upon  the  unhealthy  WK  program  in 
conjunction  with  organizational  factors  limiting  time,  scope,  and  quality. 
Enterprise  IT  projects  are  not  developed  in  a  vacuum,  and  WK  problems  infected 
MASI  as  well  as  other  systems  in  the  portfolio. 

Through  event  analysis,  several  themes  emerged  which  emphasize  the 
potential  impact  of  implicit  factors  on  portfolio  programs,  particularly  in  and 
among  complex  organizations.  The  recommendations  below  put  forth  strategies 
to  help  prevent  and  mitigate  undesirable  shocks  to  the  portfolio  from  the  factors 
discussed,  as  well  as  how  to  identify  their  effects  and  limit  their  influence. 

A.  RECOMMENDATIONS:  MANAGING  ORGANIZATIONAL  FACTORS 

FOR  PORTFOLIO  SUCCESS 

Large  organizations  and  the  accompanying  enterprise  IT  architecture 
which  complements  its  business  goals,  continue  to  increase  in  complexity. 
Awareness  of  organizational  factors  which  affect  the  IT  portfolio  is  increasingly 
critical,  yet  awareness  alone  is  insufficient.  Table  4  selects  a  key 
recommendation  for  each  implicit  factor  for  three  broad  levels  of  hierarchy: 
Senior  leaders,  middle  managers,  and  project  managers.  The  sections  below 
elaborate  on  the  recommendations. 
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Table  4.  Recommendations:  Managing  Organizational  Factors 

For  Portfolio  Success 


Recommendations  for 

Capacity 

Control 

Funding  Priorities 

Senior  Leaders 

Complete  a  portfolio  review 
prior  to  large  influxes  of 
work 

Create  a  non-punitive  vertical 
reporting  structure  and  cultivate 
both  vertical  and  horizontal 
implicit  control  networks  to 
supplement  explicit  authority 

Clear  communication  and 
transparency  should  accompany 
timely  prioritization  decisions 

Middle  Managers 

Actively  seek  out  and 
report  firefighting  trends 

Understand  and  align  with 
portfolio  goals,  providing 
honest  vertical  reporting 

Resist  local  continuation 
efforts  at  the  expense  of  the 
portfolio 

Project  Managers 

Differentiate  between 
project  problems  and 
organizational  firefighting 

Be  aware  of  implicit  control 
networks,  and  utilize  them  when 
necessary  to  further 
organizational  goals 

Provide  honest  milestone 
reporting  and  expect  timely 
notification  of  prioritization 
decisions 

1.  Systematic  mechanisms  for  understanding  and  mitigating 
capacity  problems  at  an  organizational  level  are  critical  to 
avoid  compounding  project  delays  and  portfolio  impact. 

Senior  Leaders:  Due  to  the  invisible  nature  of  capacity  issues, 
recognition  can  be  difficult.  When  the  portfolio  is  healthy,  actively  guard  against 
capacity  issues.  Perform  a  portfolio  review  prior  to  approving  commencement  of 
large  new  projects.  This  will  not  only  identify  possible  overlap  of  a  new  system 
with  existing  ones,  but  will  also  show  the  current  status  and  staffing  profiles  of 
existing  projects.  Be  vigilant  for  signs  of  organizational  firefighting,  particularly 
following  commencement  of  new  projects  or  when  experiencing  an  influx  of  work. 
Dashboard  style  reporting  systems  favored  by  senior  leaders  are  helpful,  but 
depend  on  input  from  both  middle  managers  and  project  leaders.  Create  a  non- 
punitive  reporting  atmosphere  to  encourage  honest  reporting  from  middle 
managers.  Transparency  in  leadership  is  critical,  and  the  development 
organization  should  periodically  receive  training  to  enhance  understanding  of 
organizational  goals.  Do  not  force  project  managers  to  eliminate  all  slack  time 
from  project  plans.  Do  not  expect  to  force  changes  to  an  aspect  of  the  project 
management  triangle  (scope,  funding,  or  schedule)  without  allowing 
corresponding  shift  of  the  other  elements.  Organizational  firefighting  syndrome  is 
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difficult  to  mitigate  when  in  progress.  Bohn  and  Jaikumar  (2000)  detail  tactical 
and  strategic  changes  for  immediate,  short  term  mitigation,  but  cultural  changes 
are  typically  required  for  eliminating  the  problem  and  preventing  recurrence.  In 
the  thesis  case  study,  cultural  elimination  of  slack  time,  and  constant  budget 
slashing  to  obtain  short-term  savings,  contributed  to  long  term  capacity  issues. 

Middle  Management:  Consolidate  reports  from  project  managers, 
actively  searching  for  insufficient  capacity  or  firefighting  trends.  Report  problems 
without  fear  of  repercussion.  Particular  attention  should  be  exercised  in  cases 
where  personnel  are  being  removed  from  projects  under  development  to  take  on 
new  work.  Understand  portfolio  goals  and  resist  local  optimization  at  the  expense 
of  the  portfolio.  Expect  meaningful  intervention  and  prioritization  from  senior 
leaders.  Do  not  force  removal  of  slack  time  from  project  manager  plans. 

Project  Manager:  Differentiate  between  project  problems  and 
organizational  capacity  issues.  Report  issues  to  middle  management  in  a  timely 
manner  and  expect  meaningful  intervention.  Clearly  document  project  delays 
believed  to  have  been  caused  by  capacity  issues  or  organizational  firefighting. 
Insert  reasonable  slack  time  into  project  plans  and  expect  support  from  middle 
management. 

2.  Prudent  use  of  implicit  control  by  senior  managers  can  greatly 
increase  the  chance  of  success  and  bridge  clan  divides. 

Senior  Leaders:  Do  not  discount  the  importance  of  implicit  control 
networks.  It  may  be  tempting  to  dismiss  implicit  control  concerns  as  “playing 
politics,”  but  this  is  not  the  case.  Foster  creation  of  implicit  control  networks  with 
fellow  senior  leaders  and  middle  management  of  parallel  organizations 
(departments  or  units)  to  unofficially  bridge  clan  divides.  Seek  to  use  implicit 
control  to  supplement  explicit  hierarchical  authority,  and  as  a  method  to  receive 
reports  on  portfolio  health  outside  of  official  channels.  Create  a  forum  where 
middle  management  can  discuss  portfolio  goals  without  repercussion,  to 
encourage  honest  reporting  and  exploration  of  ideas.  Implicit  control  should  not 

imply  duplicity  or  deception,  but  is  merely  an  alternate  or  supplemental  method  to 
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achieve  organizational  goals.  A  senior  leader  who  utilizes  both  explicit  and 
implicit  control  has  an  advantage  over  those  who  don’t. 

Middle  Management:  Seek  understanding  of  the  portfolio  and 
organizational  goals,  and  help  ensure  alignment  with  projects.  Discuss  perceived 
gaps  with  senior  leaders  and  provide  supporting  evidence.  Do  not  use  implicit 
control  to  implement  an  agenda  contrary  to  the  policies  of  the  organization 
(department  or  unit). 

Project  Manager:  Be  aware  of  implicit  control  networks.  Support  and 
understand  organizational  goals.  Seek  to  officially  work  through  middle  managers 
and  direct  superiors,  but  maintain  alternate  unofficial  lines  of  communication  with 
senior  leaders  when  possible.  A  redundant  implicit  control  network  can  work  to 
minimize  the  adverse  effects  of  an  incompetent  middle  manager. 

3.  Following  identification,  realistic  assessment  of  funding 
priorities  at  the  project  level  must  inform  timely  changes  to 
scope,  schedule,  and  quality. 

Senior  Leaders:  When  creating  funding  priorities,  avoid  favoritism  and 
promote  transparency.  Sound  funding  priorities  should  be  defensible  under 
scrutiny  and  align  with  organizational  goals  and  the  overall  IT  architecture.  No 
project  should  be  considered  “too  big  to  fail.”  Ensure  program  milestones  are 
meaningfully  met.  When  possible,  resolve  funding  priorities  expediently.  Do  not 
allow  a  project  to  continue  at  unsustainable  levels  when  further  funding  is  not 
available.  If  projects  must  be  truncated  or  cancelled,  timely  notification  allows  for 
graceful  project  resolution  and  archiving  of  data  for  possible  future  use. 

Middle  Management:  Do  not  obfuscate  or  alter  project  reports  to  senior 
leaders  to  disguise  problems.  Provide  honest  evaluations  of  projects,  particularly 
at  critical  milestones.  Timely  identification  of  unhealthy  projects  allows  for 
thoughtful  mitigation  and  prioritization.  When  a  project  must  be  downsized  or 
altered,  report  the  information  in  a  timely  manner  to  the  project  manager.  Allow 
time  for  project  members  to  seek  reassignment  within  the  organization,  if 
possible.  Do  not  be  tempted  to  identify  local  methods  to  enable  project 


98 


continuance  without  approval  from  senior  leaders  in  accordance  with 
organizational  goals. 

Project  Manager:  Support  project  status  reports  and  milestones  faithfully. 
Do  not  attempt  to  manipulate  data  or  figures  to  shelter  a  specific  project  or 
development  team.  Resist  clan  control  at  the  expense  of  portfolio  goals. 
Unhealthy  projects  must  be  identified  in  order  to  assess  their  continued  value  to 
the  portfolio.  Expect  timely  and  honest  feedback  from  middle  managers 
regarding  project  status  in  the  portfolio. 

4.  Summary 

An  experienced  leader  may  argue  many  of  the  recommendations  are  not 
always  possible  or  practical  to  implement.  A  situation,  in  which  total  alignment 
exists  from  senior  leader  to  the  engineer  working  on  a  project,  is  rare. 
Transparency  through  levels  of  hierarchy  is  beneficial  to  promoting 
understanding  of  organizational  goals,  but  is  rarely  understood  by  all.  A  complex 
organization  may  not  explicitly  afford  an  individual  at  a  certain  level  of  hierarchy 
to  implement  sweeping  changes  (at  this  point,  faithful  readers  of  the  thesis 
should  be  considering  implicit  control  networks).  If  nothing  else,  awareness  of  the 
effect  of  organizational  factors  on  IT  portfolio  management  and  development  will 
aid  a  good  manager  or  leader  in  performance  of  their  duties,  and  in  the  guidance 
of  those  below  them. 

B.  RECOMMENDATIONS  FOR  THE  USCG 

Implementation  of  the  recommendations  proposed  in  Section  A  would 
benefit  the  CG,  but  additional  specific  actions  would  also  be  beneficial. 

An  extensive  review  of  the  SDLC  and  MSAM/SELC  processes,  along  with 
clarification  of  responsibilities  between  CG-6  and  CG-9  would  help  limit  the 
influence  of  implicit  factors.  The  processes  were  designed  to  aid  implementation 
and  lifecycle  management  of  quality  IT  systems,  but  are  only  meaningful  when 
followed.  As  evidenced  by  event  El 8,  statements  regarding  obfuscated 
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milestone  reporting  (LaSalle,  2013),  and  various  requirements  issues,  the  SDLC 
and  MSAM/SELC  processes  are  often  circumvented  or  marginalized. 

The  COEs  (particularly  OSC  and  C3CEN)  view  themselves  as  individual 
clans,  a  view  which  is  reinforced  when  they  compete  for  funds.  They  have  areas 
of  overlapping  responsibility  which  have  allowed  redundant  development. 
Individuals  working  in  redundant  areas  exhibit  extreme  clan  behavior  in  an  effort 
to  preserve  their  positions.  Leaders  of  the  COEs  resist  what  they  see  as  loss  of 
mission  to  their  rival  COE.  These  attitudes  inhibit  cooperation  and  do  not  support 
portfolio  or  business  goals.  One  current  example  is  overlap  in  geographic 
information  systems  development  between  OSC  and  C3CEN.  Although  the 
COEs  were  re-organized  under  the  C4IT  SC,  little  meaningful  effort  has  been 
made  to  bridge  the  clan  divides.  Either  the  COEs  should  be  merged  in  some 
manner,  or  their  areas  of  responsibility  more  clearly  separated.  This  would  be  a 
contentious  process  as  each  COE  would  resist  the  changes,  but  would  result  in  a 
more  streamlined  and  efficient  organization. 

The  clan  problem  is  also  reflected  at  higher  hierarchical  levels.  As  budgets 
continue  to  shrink,  CG-6  and  CG-9  have  begun  to  compete  for  scarce  resources. 
This  reinforces  clan  behavior  at  the  expense  of  the  CG  mission  and  IT  portfolio. 
Senior  management  should  lead  by  example  in  promoting  cooperation,  rather 
than  competition,  between  directorates.  Focus  should  be  placed  on 
organizational  goals  with  a  supporting  IT  architecture,  not  in  maintaining 
directorate  power  and  structure  at  the  expense  of  the  mission.  A  cultural  shift  to 
realign  focus  may  be  necessary. 

Finally,  the  prevailing  attitude  in  the  CG  of  “doing  more  with  less”  is  often 
accompanied  by  capacity  issues,  decreased  product  quality,  and  cost  and 
schedule  overruns.  A  more  realistic  attitude  would  be  to  mitigate  capacity  issues 
by  realistically  adjusting  the  amount  of  work  and  number  of  projects  in  progress 
at  any  one  time. 
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C.  SUGGESTIONS  FOR  FUTURE  RESEARCH 

Further  studies  using  the  lens  of  organizational  factors  and  contagion 
theory  in  IT  portfolio  development  would  support  the  efficacy  of  the  theory, 
particularly  studies  performed  on  private  sector  organizations. 

Related  studies  which  increase  the  focus  on  the  implicit  activities  of  middle 
managers  and  associated  impacts  would  increase  understanding  in  this  area  and 
contribute  to  the  body  of  knowledge  touched  on  in  such  works  as  “In  Praise  of 
Middle  Managers”  (2001)  and  “Emotional  Balancing  of  Organizational  Continuity 
and  Radical  Change:  The  Contribution  of  Middle  Managers”  (2002),  both  by  Quy 
Nguyen  Huy. 

An  area  of  research  complementary  to  the  framework  prevented  in  this 
thesis  involves  the  study  of  “tensions.”  Organizational  factors  create  tension 
between  project  and  portfolio  concerns,  as  well  as  management  of  projects 
versus  management  of  portfolios.  Several  articles  have  begun  to  explore  this 
idea,  including:  “Toward  a  Theory  of  Paradox:  A  Dynamic  Equilibrium  Model  of 
Organizing”  (2011)  by  Smith  and  Lewis. 

For  the  CG,  according  to  interviews  with  several  individuals  in  CG-9333, 
CG-761,  CG-633,  and  C3CEN,  the  ambiguities  between  SDLC  and  major 
acquisitions  have  not  been  resolved.  The  time  frame  for  the  thesis  case  study 
concluded  in  February  2012,  prior  to  WK  final  development  and  production 
release.  Further  study  of  the  WK  program  would  be  pertinent  to  the  issues  raised 
in  this  study.  Following  WK  independence  from  MASI,  did  their  problems 
continue,  and  why?  Were  capacity  issues  and  firefighting  addressed?  Given  its 
limitations,  how  was  the  WK  system  received  by  end  users?  A  study  which 
focused  on  the  capacity  and  control  issues  involving  C3CEN  would  be 
illuminating.  Such  a  thesis  would  form  a  trilogy  of  theses  involving  the  WK 
system.  LCDR  LaSalle  (2013)  addressed  agile  development  and  to  a  lesser 
extent  the  HQ  middle  management  perspective,  while  this  thesis  addressed 
portfolio  concerns  and  focused  on  the  OSC  and  MASI  perspective. 
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Lessons  would  also  be  learned  from  other  long-running  and  troubled  CG 
development  projects  including  the  Vessel  Documentation  System  (VDS)  which 
took  seven  years,  and  the  Marine  Information  for  Safety  and  Law  Enforcement 
(MISLE)  version  5.0  which  has  surpassed  five  years.  Preliminary  analysis  by  the 
author  suggests  they  have  been  negatively  affected  by  implicit  organizational 
factors  and  portfolio  issues  in  a  manner  similar  to  WK  and  MASI  but  further 
analysis  may  reveal  additional  complexities. 

An  exhaustive  study  of  both  C3CEN  and  OSC  to  fully  detail  areas  of 
overlapping  development,  as  well  as  how  conflict  and  cooperation  have  affected 
the  development  of  various  enterprise  systems,  would  be  illuminating.  The 
framework  developed  in  this  thesis  would  present  an  excellent  starting  point  for 
analysis  of  the  two  COEs. 
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APPENDIX  A.  DETAILED  WK  AND  MASI  EVENT  LIST 


1 .  El :  IOC  WK  pORD  Published 

•  Description:  The  pORD  document  was  put  together  by  CG-635  and 
CG-761 .  By  design,  it  provided  a  notional,  very  high  level 
conceptual  need.  It  was  not  system  specific,  and  was  insufficient  for 
system  development,  yet  it  was  used  by  WK  for  exactly  this 
purpose  due  to  explicit  time  constraints.  The  SAFE  Port  act  of  2006 
mandated  IOC  establishment  within  three  years,  but  appropriations 
for  the  program  were  not  received  until  14  months  later,  creating 
time  pressure. 

•  Event  Type:  Explicit 

•  Severity:  3 

•  Impact:  Time:  Pressure  due  to  a  late  start  relative  to  the  SAFE  Port 
Act  requirements  (14  months  of  3  year  period)  caused 
commencement  of  design  without  proper  requirements 

•  Occurrence  Time  Frame:  April  2008 

2.  E2:  MHS-Ops  Selected  to  Fulfill  WK  IOP  Functionality 

•  Description:  MFIS-Ops  was  a  siloed  mission  and  asset  scheduling 
system  deployed  at  several  CG  sectors.  The  CG-9333  PM  hoped 
MHS-Ops  could  be  used  by  IOC  WK  with  minimal  additional 
development  work,  thus  saving  time  and  funds  which  could  be 
applied  to  other  WK  functionality. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Funding  Priority 

•  Severity:  2 

•  Impact:  Time/Cost  Avoidance:  Unrealized 

•  Occurrence  Time  Frame:  October  2008 

3.  E3:  Re-write  (MASI  Creation)  and  Discontinuation  of  MHS-Ops 
Mandated.  Port  Partner  Access  Critical 

•  Description:  After  a  technical  evaluation,  MHS-Ops  was  determined 
not  only  insufficient  as  an  enterprise  tool,  but  a  security  risk  at  CG 
locations  where  it  was  used.  CG-6  prioritized  creation  of  a 
replacement  for  MHS-Ops  for  CG  users  (MASI).  Specific  written 
requirements  did  not  exist  other  than  to  "emulate  MHS-Ops"  and 
introduce  Port  Partner  access  for  future  WK  users.  Unfortunately, 
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both  proved  problematic.  Due  to  the  siloed  nature  of  MHS-Ops,  it 
had  been  uniquely  modified  by  each  sector  at  which  it  was  used. 
Methodology  to  allow  Port  Partner  access  was  only  vaguely  defined 
by  the  pORD. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  5 

•  Impact:  Time/Cost:  Order  of  magnitude  for  entire  OSC  MASI 
development  effort  was  ~$6.5M  in  just  over  three  years.  E2  had 
hoped  for  minimal  cost  and  MHS-Ops  use.  The  cost  does  not 
include  effort  by  CG  personnel.  MASI  was  not  part  of  the  original 
IOC  WK  plan 

•  Occurrence  Time  Frame:  November  2008 

4.  E4:  MAS1 1.0  not  Accessible  by  WK  Port  Partners 

•  Description:  Port  partner  access  to  MASI  was  briefed  as  a  high  risk 
in  January  2009,  due  to  lack  of  requirements.  Under  significant 
schedule  pressure  (motivated  by  the  directive  to  replace  MHS- 
Ops),  the  MASI  team  designed  a  Port  Partner  access  solution, 
permission  for  which  was  rescinded  in  August  2009,  by  TISCOM. 
TISCOM  determined  port  partner  access  to  the  CG  Data  Network 
represented  a  security  risk.  The  MASI  team  attempted  to  salvage 
the  situation  by  moving  the  system  to  the  DMZ,  but  this  was  denied 
by  CG-635  (part  of  an  implicit  control  confrontation  with  CG-9333), 
also  due  to  lack  of  requirements.  No  other  solution  was  practical 
given  the  December  2009  production  release  date.  MASI  1.0  was 
unsuitable  for  integration  with  WK. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  8 

•  Impact:  Cost:  $150k  estimated  OSC  MASI  development  resource 

wasted  on  the  port  partner  solution.  Critically  contributed  to  E6 

•  Occurrence  Time  Frame:  August  2009 

5.  E5:  IOC  ORD  Published 

•  Description:  Although  much  more  robust  than  the  pORD,  this 
document  also  presented  high  level  operational  requirements, 
insufficient  for  system  design.  The  document  lists  WK  “Initial 
Operating  Capability”  date  of  Q4,  201 1 . 
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•  Event  Type:  Explicit 

•  Implicit  Category:  n/a 

•  Severity:  3 

•  Impact:  Time:  C3CEN  WK  development  lagging  due  to  prior  lack  of 
requirements  documents 

•  Occurrence  Time  Frame:  March  2010 

6.  E6:  WK  Insufficient  for  Production  Release,  Approved  for 
Release  as  Technical  Demonstrator  Instead,  without  MASI 

•  Description:  Release  as  a  technical  demonstrator  was  not  in  the 
WK  plan  and  was  a  last  resort  to  enable  continued  deployment 
after  an  authority  to  operate  (ATO)  was  denied  due  to  lack  of 
functionality. 

Initially,  the  [WK]  developers  broke  the  requirements  into  three 
spiral  deliverables.  The  first  spiral  would  deliver  eight  percent  of  the 
requirements,  the  second  spiral  was  slotted  to  deliver  12  percent  of 
the  requirements,  and  the  third  spiral  would  deliver  the  remaining 
80  percent  of  the  requirements.  After  missing  the  delivery  date  of 
the  first  spiral  by  114  days,  the  developers  reduced  the  targeted 
scope  by  50  percent  and  added  five  additional  spiral  releases. 
(LaSalle,  2013,  p.  52) 

Further,  the  GAO  noted: 

In  September  2009,  the  Coast  Guard  released  initial  WatchKeeper 
capabilities  to  Sector  Charleston,  South  Carolina.  However,  in 
March  2010,  an  operational  test  and  evaluation  revealed  limitations 
in  the  maturity  of  the  technology.  As  a  result,  the  Coast  Guard 
halted  further  deployment  of  WatchKeeper  to  additional  IOC 
locations.  In  May  2010,  DHS  authorized  the  IOC  project  to  release 
WatchKeeper  as  a  technology  demonstrator  to  all  35  IOC  locations. 

(2012,  p.  18) 

This  decision  removed  many  MSAM  requirements  from  WK,  but  came 
at  the  expense  of  reduced  funding  and  operational  backlash  (LaSalle, 
2013).  In  reality,  the  CG  had  hoped  to  release  WK  as  a  production 
system,  but  succumbed  to  the  technical  demonstrator  option  under 
pressure  from  DHS  (implicit  control). 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  4 
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•  Impact:  Cost:  Reduced  funding  and  operational  backlash  for  WK. 
Exact  amount  of  funding  reduction  unknown,  although  in  the 
millions 

•  Occurrence  Time  Frame:  May  2010 


7.  E7:  MAS1 1.0  Test  Deployment  Failure  at  CG  Sector  Seattle 

•  Description:  Following  the  failure  of  MASI  1 .0  to  enable  port  partner 
access  for  WK,  the  pressure  to  succeed  as  a  replacement  for  MHS- 
Ops  in  CG  use  was  intense.  The  July  2010,  test  deployment  to  CG 
Sector  Seattle  was  to  determine  if  MASI  1 .0  was  suitable.  The  effort 
was  a  failure  on  several  fronts.  In  an  effort  to  standardize  business 
processes  across  the  CG,  CG-761/CG-741  altered  them  and  did 
not  inform  or  prepare  users  prior  to  MASI  deployment.  Users 
expected  identical  functionality  and  resented  the  changes.  Critical 
design  decisions  were  made  by  CG-761/CG-741  which  in 
retrospect  were  ill-  advised.  MASI  1 .0  directly  connected  to  CG 
MISLE  in  a  way  which  made  system  use  impractical.  Although  CG- 
761/CG-741  could  have  pressed  for  release  of  MASI  1.0  and 
corrected  issues  in  later  releases,  they  labeled  the  system  a  failure. 
This  frustrated  CG-6  because  they  were  under  pressure  to 
discontinue  MHS-Ops.  Tension  between  CG-6  and  CG-7  at  senior 
levels  ensued  and  implicit  control  struggles  hampered  further  MASI 
direction  and  strategy.  Although  MASI  1.0  was  a  victim  of  incorrect 
requirements,  the  product  was  technically  competent.  The 
development  team  had  put  forth  an  incredible  effort  and  the  failure 
to  release  the  system  drastically  lowered  team  morale. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  8 

•  Impact:  Cost/Time:  OSC  MASI  team,  ~$2M  in  development  wasted 
over  18  months 

•  Occurrence  Time  Frame:  July  2010 

8.  E8:  Executive  Oversight  Council  (EOC)  "Getback"  Meeting 

•  Description:  This  critical  senior  level  meeting  (CG-6,  CG-7,  CG- 
933,  OSC,  and  C3CEN)  was  in  response  to  the  recent  failures  of 
both  WK  and  MASI.  At  a  high  level,  several  touchpoint  events  were 
identified  between  MASI  and  WK,  with  projected  completion  dates. 
Unfortunately,  the  MASI  development  team  was  not  consulted  prior 
to  delivery  promises  made  on  its  behalf  (an  event  so  significant  it 
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was  separately  noted  as  Ell).  In  addition,  the  MASI  project  was 
underfunded,  with  only  3  months  of  development  funds  available  for 
2011.  The  meeting  illustrates  a  significant  lack  of  understanding  by 
senior  leaders  of  the  complexity  and  scope  of  the  WK  and  MASI 
systems,  and  the  complexity  of  their  unresolved  dependencies. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  4 

•  Impact:  Scope/Cost:  High  level  WK/MASI  touchpoints  scheduled. 

MASI  only  25  percent  funded  for  201 1 

•  Occurrence  Time  Frame:  October  2010 

9.  E9:  IOC  APG  Published 

•  Description:  The  purpose  of  the  Interagency  Operations  Center 
(IOC)  Acquisition  Project  Guide  (APG),  written  by  CG-9333,  was  to 
define  the  relationships  between  WK  major  project  elements.  The 
guide  also  communicated  the  strategic  goals  of  the  project  and 
aligned  the  responsibilities  of  each  project  element  to  those  goals. 
Among  the  glaring  omissions  from  the  document  are  any  mentions 
of  MASI,  or  of  interoperability,  or  acknowledgement  of  OSC  as  a 
developmental  project  element.  This  reflects  the  explicit  disconnect 
between  CG-9333  major  acquisition  processes  and  CG-6  IT 
processes 

•  Event  Type:  Explicit 

•  Implicit  Category:  n/a 

•  Severity:  2 

•  Impact:  Time:  Re-baselined  WK  timelines  according  to  E8,  in 
response  to  E6 

•  Occurrence  Time  Frame:  October  2010 

10.  E10:  MRTO  Created 

•  Description:  Due  to  widely  recognized  requirements  gaps,  the  CG- 
9333  PM  provided  funding  to  OSC  for  creation  of  a  MASI 
requirements  team  (MRTO).  The  original  planned  duration  was  9 
months.  The  requirements  terminology  from  high  level  to  low  was 
“operational,”  “functional,”  and  “system.”  From  the  OSC  point  of 
view,  the  team  was  to  identify  MASI  business  processes  and  derive 
system  requirements  from  the  very  high  level  ORD  and  FRD  (yet  to 
be  delivered),  and  create  requirements  for  WK/MASI 
interconnections.  Normally,  CG-761  and  CG-741  would  have 
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gathered  end-user  requirements  and  presented  them  to  the  MASI 
team.  Capacity  issues  prevented  this  from  being  completed  in  a 
timely  manner,  a  common  HQ  middle  management  problem.  In 
addition,  the  OSC  contractor  responsible  for  staffing  the  MRTO 
team  experienced  difficulty  hiring  business  analysts.  The  team  was 
half-staffed  for  three  months. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  5 

•  Impact:  Cost:  $470k  for  a  four  person  team  over  9  months.  Not  part 
of  the  original  IOC  WK  plan 

•  Occurrence  Time  Frame:  October  2010 

11.  Ell:  EOC  Mandated  October  2011  MASI  2.0  Development 
Completion 

•  Description:  Referenced  in  E8,  this  was  the  most  egregious 
requirement  from  the  “EOC  Getback”  meeting  (from  the  MASI  point 
of  view).  The  OSC  MASI  development  team  was  asked  for  a  MASI 
2.0  development  estimate  based  on  the  high-level,  vague 
requirements  available.  MASI  2.0  was  to  support  WK  IOP 
functionality  and  incorporate  port  partners.  The  MASI  team 
estimate  was  18  months.  The  EOC  ignored  the  technical  estimate 
and  mandated  a  12  month  schedule  with  no  funding  increase  (an 
arbitrary  6  month,  33  percent  cut).  The  unrealistic  deadline  was 
designed  to  coincide  with  IOC  WK  Segment  2  SELC  activities  and 
milestone  reviews,  which  were  later  delayed,  though  a 
corresponding  MASI  delay  was  not  allowed  until  much  later.  The 
deadline  was  a  great  source  of  frustration  to  the  MASI  development 
team  who  were  expected  to  commence  development  without 
system  level  requirements.  To  mitigate  the  capacity  issue  created 
by  the  restricted  timeline,  the  idea  of  "baseline  requirements"  for 
MASI  2.0  were  created.  The  OSC  MASI  project  team  invested 
significant  time  convincing  middle  management  and  senior  leaders 
of  the  necessity  of  the  scope  reduction.  Full  implementation  of  IOP 
requirements  (in  as  much  as  they  existed)  was  not  possible  in  the 
truncated  time  frame. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  8 

•  Impact:  Time/Scope:  33  percent  compression  of  MASI  2.0 

development  schedule  forced  eventual  re-baseline  of  scope 
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•  Occurrence  Time  Frame:  October  2010 

12.  E12:  CG-633/CG-761/CG-741  MASI1.1  Prioritization  Decision 

•  Description:  Given  the  MASI  1.0  non-release  after  the  deployment 
failure  at  Sector  Seattle,  CG-6  re-emphasized  replacement  of  MHS- 
Ops  (originally  scheduled  for  shutoff  in  Aug,  2010).  The  MASI  team 
was  forced  to  shift  focus  away  from  MASI  2.0  (for  WK)  in  favor  of 
the  internal  CG  user.  MASI  1.1  Development  officially  began  Nov  3, 
2010  and  ended  Feb,  22,  2011  on  schedule.  A  follow  on  minor 
update,  MASI  1.1.1  was  released  in  April.  The  MASI  1.1  effort  was 
a  resounding  success,  at  the  expense  of  MASI  2.0  development, 
the  schedule  for  which  had  already  been  drastically  shortened  in 
Ell. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  5 

•  Impact:  Time:  Delayed  MASI  development  team  focus  on  MASI  2.0 
for  WK  by  4  months  (25  percent  of  the  12-month  truncated 
schedule  from  Ell) 

•  Occurrence  Time  Frame:  November  2010 

13.  El  3:  IOC  FRD  Published  By  CG-9333  Subcontractors.  CG-9333 
Attempts  to  Control  and  Limit  MASI  Requirements  Generation 

•  Description:  The  IOC  functional  requirements  document  (FRD)  was 

created  by  Booze  Allen  Hamilton  (BAH)  (contractor)  in  conjunction 
with  CG-9333,  with  assistance  from  CG-741.  The  MRTO  team  had 
been  told  the  document  would  enable  direct  decomposition  of 
functional  requirements  into  system  requirements  suitable  for  the 
MASI  development  team  but  this  was  not  the  case.  The  FRD 
contained  critical  gaps,  but  was  vigorously  defended  by  CG-9333  in 
an  effort  to  maintain  clan  credibility.  CG-761,  CG-741,  and  MRTO 
were  forced  to  prove  the  gaps  in  E22,  experiencing  significant 
delay. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  4 

•  Impact:  Time:  Four  month  delay  for  the  MRTO  team  as  they  were 
forced  to  significantly  add  to  this  document  (E22)  while  dealing  with 
significant  CG-9333  resistance 

•  Occurrence  Time  Frame:  November  2010 
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14.  E14:  Power  and  Control  Struggles  Begin  at  Initial  MRTO  and 
Stakeholder  (CG-9333,  CG-761,  CG-741,  C3CEN,  and  OSC) 
Meeting 

•  Description:  CG-9333  had  made  several  statements  regarding 
control  of  the  requirements  process  to  the  MRTO  team  prior  to  the 
joint  kickoff  meeting.  CG-9333  and  CG-761  /CG-741 
representatives  immediately  clashed,  and  CG-761 /CG-741 
departed  the  meeting  after  15  minutes.  The  domineering  attitude 
established  by  CG-9333  established  the  tone  going  forward.  They 
insisted  the  FRD  was  sufficient  to  generate  MASI  system  level 
requirements  and  attempted  to  directly  control  MRTO  team 
activities.  They  were  very  sensitive  to  comments  suggesting 
requirements  were  incomplete. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  6 

•  Impact:  Time/Scope:  See  El 3  impact.  In  addition,  developer  time 
and  CG  personnel  time  was  invested 

•  Occurrence  Time  Frame:  December  2010 

15.  El  5:  AMT  Non-Delivery  by  C3CEN 

•  Description:  The  failure  to  deliver  the  Account  Management  Tool 
(AMT)  by  C3CEN  was  the  first  overt  indication  of  capacity  problems 
which  impacted  MASI.  The  MASI  team  required  the  AMT  in  order  to 
design  MASI  functionality  to  authenticate  and  authorize  WK  port 
partner  entry  to  the  tool.  After  many  delays,  C3CEN  delivered  the 
AMT  10  months  late  without  required  functionality.  The  AMT  delay 
was  the  result  of  CG-9333/C3CEN  clan  control,  caused  by  capacity 
issues.  CG-9333  was  sensitive  to  schedule  delays  which  continued 
to  plague  C3CEN,  and  did  not  prioritize  the  AMT  on-schedule 
development  because  it  was  not  perceived  to  be  as  visible  as  other 
delays.  They  prioritized  C3CEN  work  to  obfuscate  capacity  issues 
to  senior  leadership.  Consideration  of  MASI  was  a  secondary 
concern,  because  they  saw  MASI  as  a  separate  clan.  This 
shortsighted  outlook  contributed  significantly  to  delays  in  WK/MASI 
interconnection  requirements  and  is  an  example  of  CG-9333  middle 
management  latitude  being  utilized  in  a  manner  contrary  to  portfolio 
goals.  When  allowed  by  CG-9333,  C3CEN  and  OSC  development 
teams  worked  well  together.  After  rearranging  the  development 
schedule  several  times,  the  MASI  team  was  forced  to  design  their 
half  of  the  AMT  interface  based  on  what  they  guessed  the  WK  AMT 
tool  might  do. 
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•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  6 

•  Impact:  Time/Scope:  The  OSC  MASI  development  schedule  was 

re-written  to  delay  development  of  MASI  modules  which  required 
AMT.  The  eventual  AMT  delivery  was  unusable  by  MASI.  Ensuing 
churn  over  the  course  of  repeated  non-delivery  and  associated 
meetings  was  1  month 

•  Occurrence  Time  Frame:  January  201 1 

16.  El  6:  CG-9333  Provided  Nine  Months  of  MASI  Funding  for  2011 
Development 

•  Description:  The  CG-9333  PM  verbally  agreed  in  July  2010  to  fund 
9  months  of  201 1  MASI  development  (MASI  2.0)  specifically  to 
satisfy  WK  requirements.  The  PM  stated  at  this  time  WK  would 
have  no  further  funds  to  supply  for  2012.  Funding  from  this  source 
was  not  ideal  because  it  further  reinforced  CG-9333  implicit  control 
over  MASI  requirements  and  schedule. 

•  Event  Type:  Explicit 

•  Implicit  Category:  n/a 

•  Severity:  4 

•  Impact:  Cost:  CG-9333  directly  and  indirectly  provided  ~1.4M  for 
OSC  MASI  2.0  development  in  2011.  This  cost  was  not  part  of  the 
initial  CG-9333  WK  plan 

•  Occurrence  Time  Frame:  January  201 1 

17.  E17:  MASI  1.1  Deployed,  Users  Happy.  CG-761/CG-741/CG-633 
Delay  Official  Release 

•  Description:  As  stated  in  El 2  MASI  1.1  was  a  success.  The 
Deployable  Operations  Group  (DOG)  was  the  primary  user  of  MFIS- 
Ops,  and  they  provided  specific  requirements  to  the  MRTO  and 
MASI  development  teams  which  were  used  to  create  the  tool. 
Several  in-progress  demonstrations  were  held  for  DOG 
representatives,  which  were  favorably  received  prior  to  final 
completion.  Although  DOG  accepted  the  tool  in  March  2011,  and 
began  to  use  it,  CG-761  did  not  authorize  official  production 
release. 

•  Event  Type:  Explicit 

•  Implicit  Category:  n/a 

•  Severity:  8 
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•  Impact:  Time:  Delayed  development  focus  on  MASI  2.0  for  WK  by  4 
months  (25  percent  of  the  12-month  truncated  schedule  from  Ell). 
(El  2  and  El  7  bookend  OSC  MASI  1 .1  development) 

•  Occurrence  Time  Frame:  March  201 1 

18.  E18:  MAS1 1.1  SDLC  Documentation  Incomplete 

•  Description:  MASI  1.1  was  not  officially  released  in  March  in  large 

part  because  CG-633  did  not  complete  the  required  SDLC 
documents.  CG-633  middle  management  was  experiencing 
significant  capacity  issues,  and  documentation  was  not  prioritized. 
The  documents  were  eventually  created  by  July  2011  but  by  then 
CG-761/CG-741  had  decided  not  to  release  MASI  1.1  beyond  DOG 
use.  Although  the  SDLC  process  was  not  properly  followed  by  HQ, 
MASI  1 .1  enabled  the  shutdown  of  MHS-Ops. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  5 

•  Impact:  Time/Quality:  CG-633  delayed  document  completion  for  4 
months 

•  Occurrence  Time  Frame:  March  201 1 

19.  El  9:  WK  Does  not  Add  Link  to  MASI  1.1  Contrary  to  EOC 
Mandate 

•  Description:  In  March  2011,  CG-761/CG-741  were  supposed  to 
allow  C3CEN  to  place  a  link  to  MASI  1 .1  on  the  WK  tool  bookmark 
page.  This  would  have  allowed  CG  WK  users  to  use  MASI  1 .1 .  The 
CG-9333  PM  requested  this  functionality  as  the  initial  link  between 
WK  and  MASI  (and  was  also  mandated  by  E8),  but  CG-761/CG- 
741  used  the  lack  of  SDLC  documentation  from  CG-633  as  a  way 
to  delay  the  request.  Following  completion  of  SDLC  documents, 
CG-633  pushed  for  the  link  to  be  placed  on  WK,  but  after  further 
delay  CG-741  officially  decided  not  to  release  MASI  1.1  for  users 
other  than  the  DOG.  The  primary  reason  for  the  decision  was  the 
ill-informed  choice  made  in  MASI  1 .0  to  tie  the  system  to  MISLE:  A 
MASI  user  required  a  MISLE  account  for  multiple  units  which  was 
not  practical.  MASI  2.0  was  to  eliminate  this  requirement  via  the 
AMT  and  disconnection  from  the  MISLE  system. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  4 

•  Impact:  Time/Quality:  MASI  1 .1  link  never  added  to  WK 
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•  Occurrence  Time  Frame:  March  201 1 

20.  E20:  MRTO  Team  Restricted  by  CG-9333 

•  Description:  The  CG-9333  PM  requested  a  BAH  member  to  serve 
as  a  requirements  subject  matter  expert  and  to  help  coordinate 
between  C3CEN  (WK)  and  OSC  (MASI)  as  necessary.  CG-9333 
felt  data  and  business  process  gathering  from  CG  Sectors  was 
exhaustive.  They  felt  any  questions  regarding  process 
requirements  could  be  answered  by  BAH  or  CG-9333.  They  placed 
extreme  restrictions  on  MRTO  interaction  with  end  users.  MRTO 
research  relating  to  back-end  system  requirement  gathering  and 
definition  were  still  deemed  necessary  (C3CEN,  ALC/ALMIS,  etc.) 
but  controlled  by  CG-9333.  CG-633,  CG-761  and  CG-741  were  at 
odds  with  CG-9333  regarding  their  restrictions  on  requirements 
gathering.  Although  CG-9333  insisted  the  MRTO  team  interact  only 
with  them,  they  did  not  have  answers  for  many  questions.  The 
MRTO  effort  was  minimally  tolerated  by  CG-9333  middle 
management,  rather  than  embraced,  delaying  progress  and 
minimizing  MRTO  effectiveness. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  5 

•  Impact:  Time:  4  month  delay  for  MRTO  team  as  they  were  forced  to 
significantly  add  to  the  FRD  (El  3,  E22)  while  dealing  with 
significant  CG-9333  resistance  which  caused  further  delay  of  2 
months,  additively  over  time) 

•  Occurrence  Time  Frame:  201 1 

21.  E21:  CG-761/CG-741  Do  not  Approve  MASI  2.0  Functional 
Requirements 

•  Description:  The  deadline  mandated  in  Ell  required  reducing  the 
scope  of  MASI  2.0  (see  Figure  4:  Project  Management  Triangle). 
CG-761 /CG-741  middle  management  agreed  to  provide  high  level 
MASI  2.0  baseline  requirements  in  March  201 1 ,  for  MRTO  to  focus 
on  decomposing  to  system  level  requirements.  CG-761 /CG-741  did 
not  deliver.  The  high  level  MASI  2.0  subset  of  requirements  was  not 
approved  until  May  (more  than  two  months  later)  following  a 
proposal  of  the  requirements  from  OSC.  The  reluctance  of  CG- 
761 /CG-741  to  formally  approve  functional  and  system  level 
requirements  would  plague  the  project  until  its  termination.  This 
was  a  reflection  of  capacity  issues  at  CG-7,  implicit  control 
difficulties  with  CG-9333  middle  management,  and  gaps  in  the  IOC 
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ORD  and  FRD.  Put  simply,  the  business  processes  which  BAH 
claimed  to  have  mapped,  were  incomplete. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  4 

•  Impact:  Scope/Quality 

•  Occurrence  Time  Frame:  March  201 1 

22.  E22:  Conflict  Over  FRD  1.1  Content  Between  CG-7  and  CG-9333 
Further  Delays  Creation  of  System  Level  Requirements 

•  Description:  Dysfunction  between  HQ  middle  management 

continued  when  incorporating  MRTO  feedback  into  the  CG-9333 
FRD.  MRTO,  CG-761,  and  CG-741  stated  the  FRD  contained  too 
many  gaps  to  allow  decomposition  to  MASI  system  level 
requirements.  CG-9333  disagreed  stating  the  FRD  was  complete. 
This  forced  MRTO  to  spend  nearly  4  months  mapping  out  gaps, 
rather  than  decomposing  the  FRD.  CG-9333  finally  admitted  the 
gaps  when  MRTO  identified  75  new  Functional  Requirements  for  a 
163  percent  increase  in  IOC  Interagency  Operational  Planning 
(IOP)  requirements.  New  functionality  included  replacement  of  the 
security  model,  a  binary  attachment  service,  and  implementation  of 
claims  based  modeling. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  5 

•  Impact:  Time:  4  month  delay  for  MRTO  (see  El 3,  E20)  while 

dealing  with  significant  CG-9333  resistance.  Also  caused  OSC 
MASI  development  churn 

•  Occurrence  Time  Frame:  April  201 1 

23.  E23:  C4IT-SC  Brief:  WK/MASI  Concerns 

•  Description:  During  this  briefing,  senior  leadership  was  officially 
informed  of: 

1.  IOC  FRD  gaps  causing  significant  delays  in  decomposing  functional 
requirements. 

2.  Lack  of  OSC  and  C3CEN  meetings  to  define  MASI  integration  with 
WatchKeeper  due  to  lack  of  CG-9333  middle  management 
prioritization  of  C3CEN  resources.  C3CEN  participation  was  required 
by  OSC  to  co-develop  the  integration  solution. 
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3.  CG-6/CG-7  were  failing  to  engage  other  enterprise  systems  (ALMIS, 
MISLE,  AOPS)  to  arrange  data  transfer  mechanisms  between 
systems. 

No  meaningful  action  was  taken  by  senior  leaders  following  this  brief. 
The  first  issue  was  a  result  of  CG-9333  middle  management  implicit 
control.  The  second  revolved  around  C3CEN  capacity  issues,  and  the 
third  involved  middle  management  capacity  issues  at  CG-6/CG-7.  CG- 
6/CG-7  capacity  issues  were  creating  episodes  of  firefighting,  and  they 
incorrectly  perceived  system  interconnect  issues  as  non-critical  at  that 
time.  They  failed  to  understand  the  significant  lead  time  and  high-level 
authorization  necessary  to  place  MASI  related  work  in  the 
development  schedule  of  several  other  enterprise  systems. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  3 

•  Impact:  Time/Scope:  Briefing  on  impacts  from  El 3,  E20,  E22,  and 
warning  of  future  scope  issues 

•  Occurrence  Time  Frame:  April  201 1 

24.  E24:  2012  MASI  Funding  in  Doubt 

•  Description:  CG-9333  had  stated  in  the  middle  of  2010  it  would  be 
unable  to  provide  any  MASI  funding  past  2011.  Rather  than 
focusing  effort  on  locating  alternate  funding  sources  for  2012,  CG- 
6/CG-7  middle  management  engaged  the  MASI  team  in  creation  of 
a  myriad  of  budget  projections,  based  on  several  different  2012 
scenarios.  Several  scenarios  involved  cutting  team  personnel  and 
reducing  the  scope  of  MASI.  In  defense  of  CG-6/CG-7  middle 
management,  there  seemed  to  be  only  token  support  from  their 
superiors  who  simply  ordered  them  to  find  solutions.  As  time 
progressed,  the  uncertainty  of  the  program's  future  impacted  MASI 
planning,  team  morale,  and  CG-9333  confidence  in  an  eventual 
MASI  system. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Funding  Priority 

•  Severity:  7 

•  Impact:  Cost/Scope:  Only  ~28  percent  of  OSC  MASI  2012  funding 
had  been  identified.  Extensive  scope  and  personnel  (cost) 
reductions  were  discussed 

•  Occurrence  Time  Frame:  April  201 1 
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25.  E25:  WK  does  not  Utilize  MASI  1.2  for  WK  State  of  the  Port  (SOP) 
Contrary  to  EOC  Mandate 

•  Description:  E8  and  E23  show  examples  of  senior  leadership 
awareness  of  the  lack  of  interoperability  between  WK  and  MASI 
due  to  lack  of  prioritization.  As  mentioned,  CG-9333  middle 
management  did  not  prioritize  the  capacity-limited  C3CEN 
development  teams  to  perform  WK  development  related  to  MASI. 
The  failure  of  the  WK  State  of  the  Port  (SOP)  display  to  incorporate 
the  MASI  1.2  ESB  data  feed  was  another  example.  Senior  leaders 
had  mandated  WK  use  of  MASI  1.1  and  1.2  in  E8.  The  lack  of  the 
MASI  1 .1  link  on  WK  was  detailed  in  El  9.  The  MASI  team  designed 
1.2  on  schedule  and  waited  for  C3CEN  to  complete  their  SOP  to 
enable  testing  of  the  data  service.  C3CEN  moved  implementation 
from  June  201 1 ,  to  Feb,  201 2  (8  months).  In  November  201 1 ,  CG- 
741  officially  decided  not  to  deploy  MASI  1 .2  until  MASI  2.0  went  to 
production.  The  continual  delays,  lack  of  senior  leadership  support, 
and  disregard  by  CG-9333  for  the  OSC  team  caused  MASI 
schedule  churn  and  morale  issues. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  4 

•  Impact:  Cost/Time:  $100k  estimated  OSC  MASI  development 

resource  wasted.  Also  caused  MASI  schedule  churn  which  later 
wasted  another  month  for  1  developer.  MASI  1.2  was  never  utilized 
by  WK 

•  Occurrence  Time  Frame:  June  201 1 

26.  E26:  Change  of  CG-9333  PM 

•  Description:  The  outgoing  CG-9333  PM  was  responsible  for  funding 
MRTO,  and  9  months  of  MASI  2011  development,  as  well  as  the 
initial  decision  to  use  MASI  for  WK  IOP  functionality.  Although 
senior  leadership  (including  the  PM)  in  general  disregarded  MASI 
issues,  the  PM  supported  MASI  integration  under  WK.  As  an  effort 
to  ensure  WK/MASI  integration  following  his  departure,  the  PM 
wrote  an  official  memo  detailing  high  level  MASI  2.0  requirements. 
Following  his  departure,  however,  the  inexperienced  incoming  PM 
was  overly  susceptible  to  mid-level  CG-9333  management  input. 
The  CG-9333  middle  managers  had  firmly  established  their  clan 
mentality  with  an  ongoing  lack  of  prioritization  for  WK/MASI 
interconnection  issues,  and  restriction  and  delay  of  the  MRTO 
mission.  Their  attitude  was  transmitted  to  the  new  PM  who  seemed 
to  view  MASI  as  a  necessary  impediment. 
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•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  5 

•  Impact:  Loss  of  CG-9333  senior  level  champion  of  the  OSC  MASI 
team 

•  Occurrence  Time  Frame:  June  201 1 

27.  E27:  MASI  Development  Team  Begins  RAD/JAD  Methodology 

Description:  CG-9333  interference  in  MRTO  system  requirements 
generation  and  the  delays  caused  by  resolution  of  FRD  gaps  resulted 
in  the  OSC  development  team  "catching  up"  to  requirements 
generation.  The  team  had  been  designing  infrastructure  and  back  end 
services  based  on  lessons  learned  from  MASI  1.0,  but  had  reached 
the  point  where  further  development  could  no  longer  proceed  without 
new  system  requirements.  The  prior  pseudo-waterfall  method  was 
discontinued  in  favor  of  the  RAD/JAD  agile  development  approach, 
which  focused  on  defining  system  level  requirements  with  developer 
input,  immediately  before  official  coding  of  each  MASI  module.  The 
effort  was  also  designed  to  assist  the  capacity  constrained  CG- 
761/CG-741/CG-633  middle  management  representatives  by 
incorporating  their  feedback  during  the  JADs.  CG-761/CG-741  were 
responsible  for  representing  users  by  delivering  requirements.  MRTO 
members  transcribed  requirements  created  during  JADs,  but  obtaining 
timely  approval  of  these  requirements  by  middle  managers  remained 
a  critical  problem  and  source  of  delays. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  4 

•  Impact:  Time/Scope:  New  methodology  to  enable  near-concurrent 

requirements  definition  and  system  development 

•  Occurrence  Time  Frame:  July  201 1 

28.  E28:  Status  Brief  to  Assistant  Commandant  for  U.S.  Coast  Guard 
Capability  (CG-7  RDML) 

•  Description:  Another  brief  to  senior  leadership  which  focused  on 
issues  involving  MASI  development.  By  this  time,  senior  leadership 
was  accustomed  to  "MASI  problems,”  but  the  OSC  MASI  team  was 
rarely  the  cause  of  these  issues.  Although  successfully  deployed  to 
the  DOG,  the  official  MASI  1.1  deployment  decision  still  resided 
with  middle  management  at  CG-761/CG-741 .  MASI  1.2  deployment 
(completed  by  OSC)  awaited  C3CEN  implementation  of  the  WK 
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portion.  MASI  2.0  development  (already  on  an  unrealistic  schedule) 
was  delayed  by  resolution  of  FRD  gaps,  interference  through  both 
CG-9333  action  and  non-action,  and  non-delivery  of  the  AMT  by 
C3CEN.  The  series  of  shocks  to  the  MASI  schedule  and  team  from 
WK  and  CG-9333  were  visibly  affecting  the  MASI  effort.  Lack  of 
interoperability  requirements  between  WK  and  MASI  were  again 
highlighted,  as  well  as  lack  of  identification  of  2012  MASI  funds. 
MASI  2.0  delivery  in  October  was  at  risk.  Once  again,  senior 
leadership  made  only  token  gestures  at  resolution  of  issues. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  3 

•  Impact:  Time/Cost/Scope:  Briefed  on  impacts  from  Ell -El 5,  El  7- 
E25,  and  E27 

•  Occurrence  Time  Frame:  July  201 1 


29.  E29:  MRTO  Staffing  Issues/MRTO  Extension 

•  Description:  Delays  in  requirements  generation  prompted  MRTO 
team  extension  to  end  of  2011  and  slippage  of  deliverables.  Initial 
staffing  difficulties  and  departure  of  an  analyst  allowed  the 
extension  to  the  remaining  team  under  the  original  funding  amount. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  3 

•  Impact:  Time:  6  Month  MRTO  team  extension  (see  El  3,  E20,  E22) 

•  Occurrence  Time  Frame:  July  201 1 

30.  E30:  CG-9333  Pushes  for  Fundamental  Changes  in  WK/MASI 
Interconnection  (Object  Level  Linkage) 

•  Description:  The  original  CG-9333  PM  (who  departed  in  E26)  had 
mandated  all  WK/MASI  intersystem  connectivity  take  place  via  ESB 
in  support  of  CG  policy  and  given  WK  technical  limitations.  CG- 
9333  middle  management  finally  realized  this  limitation  would 
impact  desired  WK  user  performance.  No  solution  was  readily 
available  because  interoperability  concerns  had  been  repeatedly 
delayed  due  to  C3CEN  capacity  issues  and  lack  of  CG-9333 
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prioritization.  Clan  mentality  continued  to  dominate  CG-9333  and 
reinforced  their  perception  of  MASI  as  a  liability. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  6 

•  Impact:  Scope 

•  Occurrence  Time  Frame:  July  201 1 

31 .  E31 :  MASI  2.0  Non-delivery  to  WK  for  Integration 

•  Description:  Delivery  of  MASI  2.0  in  October  of  2011  was  an 
artificial  deadline  created  by  senior  management  (E8,  Ell)  when 
only  rudimentary  business  requirements  had  been  defined.  Given 
no  extra  resources  and  a  reduced  timeline,  the  MASI  team  was 
forced  to  re-define  MASI  2.0  functionality  (project  management 
triangle).  The  delays  and  issues  detailed  in  E12-E26,  and  E28-E30 
compounded  and  built  upon  one  another  to  infect  MASI 
development  and  made  delivery  in  October  impossible.  C3CEN  had 
not  completed  the  AMT  tool  to  enable  critical  MASI  development. 
System  requirements  were  still  incomplete  in  October.  By  June 

2011,  WK  had  delayed  planned  MASI  2.0  integration  until  April 

2012,  yet  a  corresponding  MASI  development  schedule  slip  was 
denied.  Although  senior  leadership  had  been  briefed  on  the  serious 
issues  facing  MASI  development  which  were  beyond  the  authority 
of  the  MASI  team  to  control,  they  did  not  meaningfully  intervene. 
The  unjust  perception  of  MASI  as  a  problem  project  was  magnified 
by  this  event,  although  it  should  have  surprised  no  one.  MASI  team 
morale  continued  to  degrade  and  team  members  began  to  resign. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  7 

•  Impact:  Time/Cost:  Total  OSC  MASI  development  cost  from 
inception  to  this  date  was  roughly  $5.8M.  The  only  system  fielded 
at  this  time  was  MASI  1.1,  used  by  CG  DOG.  WK  had  not  created 
the  AMT,  or  integrated  MASI  1.1  or  1.2,  and  2.0  was  not  delivered 
(for  reasons  described  in  Ell -El 5,  E20-E23,  and  E28-E30) 

•  Occurrence  Time  Frame:  October  201 1 

32.  E32:  CG-9333  Directs  WK/MASI  Technical  Interface  Meetings  be 
Delayed  Until  December  2012 
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•  Description:  Although  many  MASI  issues  were  directly  and 
indirectly  influenced  by  CG-9333  middle  management  decisions, 
non-delivery  of  MASI  2.0  was  interpreted  by  the  CG-9333  PM  as 
OSC  MASI  development  team  unreliability.  He  began  to  influence 
CG-741  senior  leadership  with  this  view.  WK  (C3CEN)  was  once 
again  late  with  a  service  pack  delivery  (capacity)  and  CG-9333, 
operating  on  clan  control  assumptions  and  engaging  in  firefighting, 
further  delayed  meetings  between  OSC  and  C3CEN  which  would 
define  system  touchpoints  and  interoperability.  The  AMT  and  port 
partner  requirements  were  further  delayed,  which  in  turn  delayed 
MASI  development  of  corresponding  modules.  The  CG-9333  PM 
did  not  view  C3CEN  work  as  superior  to  that  of  OSC  (given  their 
repeated  delays)  but  he  viewed  WK  as  part  of  his  clan  and 
prioritized  for  them.  The  WK  program  had  been  investigated  by  the 
GAO  and  downgraded  from  major  acquisition  status  due  to 
sustained  capacity  and  development  issues  at  C3CEN,  in  large  part 
caused  by  lack  of  useable  WK  requirements  from  BAH.  The 
downgrade  removed  further  SELC  milestone  requirements,  but 
impacted  WK  funding. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  5 

•  Impact:  Time/Scope:  WK/MASI  interconnection  definitions  and  AMT 

requirements  delayed  another  6  weeks.  Caused  further  churn  to  the 
OSC  MASI  2.0  development  schedule 

•  Occurrence  Time  Frame:  October  201 1 

33.  E33:  Competition  for  2012  Funds  Between  WK  and  MASI 

•  Description:  The  only  funds  identified  by  CG-633/CG-761  middle 
management  for  MASI  were  also  claimed  by  CG-9333  for  WK. 
Global  budget  cuts  and  a  C4IT-SC  fee  levied  on  programs, 
combined  with  the  lack  of  funding  emphasis  by  HQ  middle 
management  (despite  continued  warnings  from  the  MASI  team 
which  had  begun  7  months  prior)  made  the  issue  critical.  The  CG- 
9333  WK  acquisition  was  mandated  by  congress,  and  they  were 
certain  they  would  receive  the  money.  For  reasons  not  known  to 
the  author,  the  CG-761  directorate  head  was  certain  the  funds 
would  go  to  MASI.  Also  for  unknown  reasons,  CG-761  middle 
management  broke  away  from  the  directive  of  their  superior  and 
influenced  the  final  decision  to  allocate  funds  to  WK.  The  true  error 
was  in  allowing  competition  for  funds  between  codependent 
programs.  CG-9333  began  to  quietly  investigate  alternatives  to 
MASI. 
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•  Event  Type:  Implicit 

•  Implicit  Category:  Funding  Priority 

•  Severity:  9 

•  Impact:  Cost:  CG-633/CG-761  on  behalf  of  OSC  MASI,  and  CG- 
9333  on  behalf  of  C3CEN  WK  both  tried  to  obtain  the  same  $1 .3M 
for  2012 

•  Occurrence  Time  Frame:  September  201 1  -January  201 2 

34.  E34:  MASI  Status  Brief  to  RDML  (CG-7)  and  SES  (CG-6) 

•  Description:  From  the  senior  leadership  perspective,  this  brief  again 

focused  on  MASI  development  and  release  problems.  The  official 
decision  not  to  place  MASI  1.1  into  production  (beyond  DOG  use) 
was  announced  (middle  management  decision), the  decision  not  to 
deploy  MASI  1.2  until  MASI  2.0  rolled  was  announced,  as  well  as 
failure  to  complete  development  on  MASI  2.0.  The  toll  on  the  MASI 
development  team  had  become  critical  as  they  announced  a  2 
month  overall  delay  due  to  loss  of  the  senior  database  designer 
and  a  critical  middleware  developer.  The  middleware  developer 
was  not  replaced  due  to  2012  funding  uncertainty.  The  opinion  of 
senior  leadership  (with  the  exception  of  the  CG-761  director) 
continued  to  turn  against  MASI  as  a  viable  option,  particularly  that 
of  the  CG-9333  PM. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  5 

•  Impact:  Cost/Time/Scope:  Briefed  events  to  this  point.  OSC  MASI 

announced  an  additional  2  month  delay  due  to  attrition  of  critical 
team  members 

•  Occurrence  Time  Frame:  November  201 1 

35.  E35:  CG-9333,  CG-741,  and  CG-761  Hold  "Simple  Scheduler" 
Meetings  Without  Notifying  OSC 

•  Description:  The  CG-9333  PM  directed  his  middle  management  to 
create  an  approach  that  would  allow  them  to  officially  separate  from 
MASI  if  given  RDML  approval.  CG-741  and  CG-761  middle 
management  assisted.  CG-633  and  OSC  were  not  informed.  This 
was  motivated  not  only  by  loss  of  confidence  in  MASI,  but  also 
heavily  influenced  by  E30  and  continued  CG-9333/CG-741 
reluctance  to  implement  MASI  solutions,  or  to  define 
interconnection  requirements.  They  created  the  concept  of  a 
"simple  scheduler"  which  would  run  natively  under  WK  (solving 
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E30),  with  minimal  automated  functionality.  Many  WK  IOP  actions 
would  be  performed  manually  by  IOC  personnel  to  satisfy  high-level 
congressional  requirements.  CG-9333  planned  for  the  perennially 
resource  constrained  developers  at  C3CEN  to  implement  the 
"Simple  Scheduler"  (although  C3CEN  would  no  longer  be  required 
to  interact  with  MASI)  illustrating  a  reciprocal  effect  where 
continued  neglect  of  MASI  caused  additional  work  for  WK.  C3CEN 
at  the  developer  level  is  not  believed  to  have  been  initially  aware  of 
this  because  they  were  later  forced  to  create  a  “level  of  effort”  for 
the  undertaking. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Control 

•  Severity:  6 

•  Impact:  Time/Scope:  An  increase  in  C3CEN  WK  time  (est.  3-4 
months)  and  change  to  scope,  in  an  attempt  to  remove 
dependence  on  MASI 

•  Occurrence  Time  Frame: 

36.  E36:  MASI  2.0  Demonstration  to  Senior  Stakeholders/Funding 
Pitch 

•  Description:  The  OSC  MASI  team  and  OSC  leadership  believed 
MASI  development  would  be  canceled.  The  MASI  technical  lead 
and  the  author  presented  a  MASI  functional  demonstration  at  HQ  to 
several  key  stakeholders,  including  0-6s  from  CG-741,  CG-9333, 
CG-761,  CG-633,  and  OSC  in  an  effort  to  save  the  program.  The 
demonstration  focused  on  the  extensive  MASI  2.0  functionality 
already  completed  at  that  time.  All  attendees  were  impressed  (The 
CG-761  directorate  head  labelled  the  result  "visionary,”  and  "the 
future  of  the  CG"),  but  unfortunately  no  source  of  MASI  funding  for 
2012  was  identified.  CG-741  verified  that  even  if  MASI  funding 
were  found,  the  MASI  team  would  not  develop  the  “simple 
scheduler”  as  defined,  but  would  revert  to  prior  MASI  2.0 
requirements,  which  were  still  incomplete.  The  remaining 
motivation  for  MASI  development  was  enterprise  CG  use  beyond 
the  DOG. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Funding  Priority 

•  Severity:  7 

•  Impact:  None  beyond  support  of  CG-761.  An  attempt  to 

demonstrate  the  value  of  MASI  development  to  date,  and  the 
potential  presented  by  the  system 
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•  Occurrence  Time  Frame:  January  201 2 

37.  E37:  RDML  CG-7  Memo:  MASI  No  Longer  to  Provide  Any 
Functionality  for  WK 

•  Description:  This  official  memo  allowed  WK  to  develop  the  "Simple 
Scheduler"  and  voided  MASI  as  the  system  to  complete  WK  IOP 
requirements.  The  RDML  noted  insufficient  funds,  lack  of 
requirements,  and  loss  of  WK  segment  2  as  factors  (a  combination 
of  E6.  and  WK  downgrade). 

•  Event  Type:  Explicit 

•  Implicit  Category:  n/a 

•  Severity:  8 

•  Impact:  Cost/Time:  CG-9333  wasted  an  estimated  $4M-$5M  by 
eliminating  MASI  from  eventual  use  in  WK,  and  added  3-4  months 
of  development  effort  to  C3CEN  WK  for  the  Simple  Scheduler 

•  Occurrence  Time  Frame:  January  2012 

38.  E38:  CG-761  Provides  $200k  Interim  MASI  Funding 

•  Description:  Extensive  budget  meetings  were  held  with  the  C4IT- 
SC  in  an  attempt  to  identify  MASI  2012  funding.  A  full  year 
commitment  was  not  forthcoming  but  CG-761  pledged  to  send  an 
FTA  of  $200k  to  OSC  to  keep  the  development  team  in  place  until 
the  end  of  February.  At  that  time  a  final  funding  decision  was  to  be 
made.  Even  at  that  point,  in  the  face  of  all  opposition,  the  CG-761 
directorate  head  believed  the  program  would  continue.  He  stated: 

I  am  tired  of  discussing  getting  an  RP  for  MASI.  I  expect  the  C4ISR 

RC  to  use  our  working  capital  fund  to  develop  MASI  and  eliminate 

AOPS/TMT  and  ALMIS/EAL.  This  is  not  a  secret.  I  expect  all  to 

follow  my  direction  AND  EXECUTE  THE  DIRECTION.  (Personal 

communication,  January  25,  2012) 

Despite  this  directive,  CG-761  middle  management  continued  to 
undercut  MASI  and  recommend  cessation  of  development. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Funding  Priority 

•  Severity:  3 

•  Impact:  Cost:  $200k 

•  Occurrence  Time  Frame:  January  2012 
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39.  E39:  Loss  of  55  Percent  of  MASI  Team  Over  Four  Months, 
Including  Technical  Lead  and  Senior  Developer 

•  Description:  Morale  on  the  OSC  MASI  development  team  had 
continued  to  degrade  due  to  the  compounding  events  involving  CG- 
9333,  WK,  and  HQ  middle  management.  The  contagion  had 
reached  a  critical  point.  The  message  was  continually  delivered, 
directly  and  indirectly,  that  MASI  was  not  worthy  of  prioritization. 
From  October  2011,  to  February  2012,  55  percent  of  the  OSC 
MASI  development  team  resigned.  Loss  of  the  team  technical 
leader  was  the  final  blow  from  which  development  could  not 
recover  on  any  practical  timeline.  At  this  time  the  author 
recommended  cessation  of  development  and  maintenance  of  MASI 
1.1  for  DOG  use  (which  continues  to  the  date  of  this  writing). 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  8 

•  Impact:  Time:  Undefined  delay,  minimum  5  months,  to  allow 
rebuilding  and  training  of  new  OSC  MASI  team  (was  not  attempted) 

•  Occurrence  Time  Frame:  October  201 1  -February  201 2 

40.  E40:  Course  of  Action  (COA)  EOC  Meeting 

•  Description:  The  official  meeting  where  MASI  development  was 

indefinitely  halted.  Operations  and  maintenance  funding  was  used 
to  sustain  MASI  1.1  operation  for  the  CG  DOG  users. 

•  Event  Type:  Implicit 

•  Implicit  Category:  Capacity 

•  Severity:  10 

•  Impact:  Cost:  As  noted  in  E3,  ~$6.5M+$470k  (MRTO).  MASI  1.1 
development  was  a  modest  ~$650k  and  was  the  only  version 
released  for  use  (CG  DOG) 

•  Occurrence  Time  Frame:  February  2012 
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APPENDIX  B.  MASI  1 .1  TO  2.0  ARCHITECTURAL  CHANGES 


MASI  1.1  Architecture 

MASI  1.1  consists  of  a  single  user  interface  that  bridges  data  from  two  back-end 
information  systems.  The  user  interface  is  built  in  Silverlight  3.0.  It  communicates  via 
traditional  SOAP  communications  to  a  WCF  data  service  (web  service).  The  data  service 
coordinates  calls  to  two  SQL  Server  persistent  data  stores  (MASI  and  MISLE)  to  fulfill 
data  requirements. 

All  users  of  MASI  1.1  are  members  of  the  Coast  Guard  Active  Directory  deployment. 
User  authentication  is  handled  via  traditional  authentication  methodologies  in  a  single¬ 
sign  on  scenario  (Kerberos  and  NTLM).  In  addition,  all  users  are  accessing  the  application 
via  the  CGDN  only.  No  DMZ  access  is  currently  available. 

To  facilitate  MASI  1.1  capabilities,  we  addressed  the  following  key  components: 

1.  Users  and  the  security  model  for  the  application. 

2.  Coast  Guard  hierarchy. 

3.  Coast  Guard  Resources. 

4.  Appointments. 

Users  and  the  security  model  for  the  application 

In  1.1,  MASI  has  strict  relationships  with  user  account  management  processes  in 
MISLE.  The  model  is  based  on  explicit  approvals  for  a  user-to-Coast-Guard-unit 
inside  the  MISLE  database.  Direct  calls  from  MASI  to  MISLE  are  utilized  to  validate 
what  units  a  given  user  has  authority  to  access  when  the  user  logs  into  the  MASI 
application. 

Coast  Guard  Unit  Hierarchy 

MASI  1.1  uses  data  stored  in  MISLE  to  generate  a  hierarchical  representation  of 
units.  Data  used  includes  the  MISLE  unit  table  coupled  with  the  AOPS  unit 
reference  data  which  contains  a  recursive  relationship  to  drive  parent-child 
hierarchy. 

Coast  Guard  Resources 

MASI  1.1  uses  data  stored  in  MISLE  to  generate  resource  listings  for  each  unit. 
These  resources  include  AOPS  and  ALMIS  reference  data  representing  resources 
from  those  systems,  in  addition  to  MISLE  local  resource  data. 

Appointments 

The  data  pertaining  to  the  scheduling  of  resources  (units  and  physical  assets)  is 
housed  in  the  MASI  data  store. 
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MASI  2.0  Scope  &  Architecture 

Some  of  the  MASI  2.0  requirements  drove  goals  like  decoupling  from  MISLE,  obtaining 
information  directly  from  systems  of  records,  addressing  port  partner  capabilities 
(including  existing  user  identity  stores),  expansion  of  the  application  presence  to  a  new 
security  domain  (DMZ),  and  publishing  of  data  after  modifications  to  other  systems. 
MASI  2.0  was  a  fundamental  architectural  redesign. 

Architectural  goals  included  utilizing  the  Coast  Guard's  Enterprise  Service  Bus  to  obtain 
the  information  necessary  to  fulfill  system  requirements  by  establishing  data  feeds  from 
the  Coast  Guard  IT  systems  designated  as  "systems  of  record."  Also,  due  to  the 
introduction  of  a  new  security  zone  (DMZ)  and  users  from  a  disparate  identity  store,  a 
solution  had  to  be  addressed  to  facilitate  user  authentication  and  authorization.  This 
solution  also  came  into  play  when  accessing  data  inside  the  Coast  Guard  Data  Network. 
Some  of  the  data  presented  back  to  the  client  needed  to  be  filtered,  masked,  or  in  some 
cases,  not  even  sent  back  to  the  consuming  user  interfaces. 

To  facilitate  MASI  2.0  capabilities,  we  addressed  the  following  key  components: 

1.  Identify  solution  for  user  authentication/authorization  in  multiple  security 
zones. 

2.  Identify  data  sources  necessary  to  fulfill  decoupling  (hierarchy  &  resources). 

a.  Establish  tools  for  ESB/SOA  interaction 

b.  Establish  data  feeds  with  necessary  systems  of  record. 

3.  Identify  solution  for  the  data  tier  to  support  data  masking,  filtering,  or 
omission  based  on  user  permissions. 

4.  Implement  new  requirements  for  port  partner  capabilities. 

a.  Account  management 

b.  Ability  to  create/manage  port  partner  organizations  &  resources. 

c.  Integration  with  Coast  Guard  capabilities. 

5.  Implement  solution  to  support  transmission  of  data  after  modification. 


User  Authentication/Authorization 

Our  immediate  goals  focused  on  addressing  an  interoperable  solution  for  solving 
user  authentication/authorization  in  a  solution  based  on  multiple  security 
domains.  To  address  this,  we  externalized  these  capabilities  to  a  security  token 
service  and  built  in  application  trusts  to  these  capabilities.  Authentication  and 
authorization  data  was  passed  using  industry  standard  xml-based  SAML  tokens. 

These  tokens  allow  for  interoperability  between  C3CEN  WatchKeeper  capabilities. 
Juniper  device,  MASI  user  interface,  and  MASI  data  services. 

Establish  tools  for  ESB/SOA  interaction 
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Tooling  was  developed  to  work  with  the  Coast  Guard  ESB  to  facilitate  the  sending 
and  receiving  of  data  necessary  to  fulfill  decoupling  from  MISLE. 

Establish  data  feeds  with  necessary  systems  of  record 

Extensive  work  has  been  performed  from  the  PSOA,  MISLE,  MASI,  ALMIS,  and 
AOPS  teams  to  fulfill  MASI  2.0  data  requirements. 

Identify  solution  for  the  data  tier  to  support  data  masking,  filtering,  or  omission 
based  on  user  permissions 

MASI  2.0  data  services  have  been  re-engineered  to  take  advantage  of  the  WS-* 
specification.  Utilizing  WS-Federation,  we  are  able  to  apply  logic  decisions  on  data 
calls  that  can  impact  what  data  is  returned  to  the  clients. 

Implement  new  requirements  for  port  partner  capabilities 

Additions  were  made  to  SQL  Server  to  facilitate  requirements  additions  to  support 
port  partner  capabilities.  The  data  services  were  extended  to  support  a  hierarchy 
of  Coast  Guard  departments  and  port  partner  organizations. 

Author,  William  Saunders,  MASI  Team  Technical  Development  Lead 
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APPENDIX  C.  MASI  TEAM  OF  THE  QUARTER  AWARD  (MASI 
1-1) 


The  Operational  Systems  Center’s  (OSC)  Mission  and  Asset  Scheduling 
Interface  Team  is  cited  for  superior  performance  and  outstanding  teamwork 
during  this  period,  specifically  the  successful  development  and  release  of  a  major 
system  upgrade. 

MASI  is  a  web  enabled  tool  to  support  operational  planning  and  current 
asset  status,  providing  a  means  to  capture  planned  and  executed  operations  for 
USCG  and  port  partners  as  required  by  the  Security  and  Accountability  for  Every 
(SAFE)  Port  Act. 

Timely  requirements  definition  and  superlative  work  by  the  development 
team,  while  adhering  to  a  very  tight  schedule,  enabled  the  successful  release  of 
a  major  update  to  the  MASI  system.  The  system  update  incorporates  extensive 
new  functionality  and  performance  enhancements:  redundant  data  transfer  was 
reduced  by  73  percent,  data  payload  size  by  65  percent,  and  the  returned 
payload  was  compressed  by  33  percent.  The  release  enabled  CG  use  of  MASI  5 
months  sooner  than  the  originally  projected  solution  and  allowed  termination  of 
the  non-enterprise  MHS-OPS  program.  Quality  of  design  and  ease  of  use 
allowed  quick  adoption  of  the  tool  by  the  entire  CG  Deployable  Operations  Group 
(DOG)  and  27  subunits,  as  well  as  facilitating  area  and  district  users.  To  date, 
DOG  users  have  created  over  1400  Missions.  The  PACAREA  Chief  of  Response 
(PAC-33)  conveyed  his  satisfaction  and  lauded  MASI  as  a  “great  success  story 
of  collaboration.”  In  the  same  release,  the  team  also  completed  development 
work  on  a  Tasked  Asset  data  service  for  IOC  WatchKeeper  to  support  maritime 
awareness  for  the  USCG,  DHS  and  DOD  Port  Partners.  Close  coordination 
between  C3CEN  and  the  team  enabled  the  data  service  delivery  5  weeks  before 
required  date. 

Also  during  this  period,  extensive  work  was  completed  on  the  next  major 

release  which  will  enable  direct  nationwide  port  partner  access  and  participation 
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in  the  MASI  lOC/Watch Keeper  scheduling  process.  The  team  bridged  gaps 
between  HQ  program  sponsors,  CG-9333  and  fellow  Centers  of  Excellence 
(COEs)  while  identifying  75  new  Functional  Requirements  for  a  163  percent 
increase  in  IOC  Interagency  Operational  Planning  (IOP)  requirements.  New 
functionality  included  replacement  of  the  security  model,  a  binary  attachment 
service,  and  implementation  of  claims  based  modeling.  Superior  teamwork  was 
demonstrated  in  collaboration  with  Emerging  Technologies  (ET)  in  the 
establishment  of  a  baseline  .NET  enterprise  ESB  client  and  security  token 
service  capabilities  as  an  enterprise  solution  for  authentication  and  authorization. 
Subsequent  release  will  promote  interagency  asset  utilization  and  mission 
coordination,  projected  to  save  millions  of  dollars  each  year. 
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